I wrote a simple code that makes an object follow moursor or touch input and works so fast and responsive on editor but when I deploy it on my iPod, it has a slight delay. If you move your finger fast enough, you can see that the object takes time to reach to your finger, it's slight but noticable.
There is no problem in the path that object has to follow in order to get dragged around the scene, problem is it's always like 10 pixels late to the finger's current position. It's like input is checked on less intervals than update.
So is there anyway to make it more responsive? Like with what we can do with physic that we can force it to call more Fixed Update or anything similar.
I want it to follow my finger on the screen fast, without any delay.
I tried these so far with no fruit:
1) Changing FPS ro 60.
2) Changing various settings in AppController.mm
Thanks.
Related
Im using Swift 3.0 and I'm attempting to use the SKCameraNode class as a camera for my game.
I move it around, rotate, and zoom in and out a lot. For some reason, it goes in and out of having these rough patches (about 30 seconds) where it's super etchy, as if it were only being updated a tenth of the usual time. Note that NOTHING else in the game is lagging except camera movement.
However this is only extremely noticeable when I'm trying to zoom in and out.
The occurrence usually happens after a burst of moving it around a lot, but not always. Sometimes it happens the second the app is started, and other times never.
Here is my code, which is running in didFinishUpdate:
camera.run(SkAction.scale(to: size, duration time))
time is usually 0.0, but sometimes not, so I would like to try to keep this as an SKAction if possible. However, I assume the problem resides in using this SKAction. (I'm like 99% sure the problem isn't that I'm accidentally not passing 0.0 for time)
So what should I do to either fix or work my way around this problem? Is this just a limitation of a Swift?
EDIT: I have now also tried using it in other update functions. I also tested to see the run time of didFinishUpdate (To see if it was lag), but it remained consistent. Also, this happens when i try to rotate the camera as well.
ANOTHER EDIT: I've also tried setting gamePhysics speed to 0.9999 which was suggested in another post with a lag problem
Thanks!
I have programmed an Ipad application that has a behaviour that I would like to change if I put it in a wooden frame (any other material could be added). To simplify things, the background should change whenever is inside this frame, and there must be no tap-touch interaction, just putting the Ipad inside the frame.
Of course, we could program am specific gesture on the screen, like double tapping or swiping but it is not the searched solution.
Another thought has been to detect the lack of movement for a certain amount of time, but that would not assure that iPad is inside the frame.
I have thought about interacting with magnets (thinking about smartcovers) and the sleep sensor in the right side of the Ipad, but I don't know how to do it.
I cannot see any other useful sensor.
Any suggestion?
A combination of accelerometer and the camera seems like an idea worth trying out:
Scan the accelerometer data to detect a spike followed by a flat line (= putting the iPad into the frame, then resting).
After detecting the motion event, use the back camera (maybe combined with the flash) to detect a pattern image fixed inside of the frame for this purpose. It might be necessary to put the pattern into a little hole to create at least a blurry image.
The second step is there to distinguish the frame from any other surface the iPad might be placed upon.
I am creating a game using cocos2dx 2.1.4. Its FPS drops continuously , and never recover.
Please find the details as follows
Background about the way I am doing things:-
Its game about scrolling down some shapes, each shape is made up of some square blocks.I have 7 kind of blocks. All loaded in a Sprite Sheet and using these blocks from this sprite sheet I create a shape.
A level file is consist of these shapes. I load two levels at the same time one onscreen and another off screen to make it seamless scrolling. For loading two levels at the same time I used two different CCSprite game batch nodes as :-
CCSpriteFrameCache::sharedSpriteFrameCache()->addSpriteFramesWithFile("56blackglow.plist");
_gameBatchNode1 = CCSpriteBatchNode::create("56blackglow.png", 200);
_gameBatchNode1->retain();
this->addChild(_gameBatchNode1,kForeground);
_gameBatchNode2= CCSpriteBatchNode::create("56blackglow.png", 200);
_gameBatchNode2->retain();
this->addChild(_gameBatchNode2,kForeground);
The problem I am facing is that as I keep on playing the game frame rate drops continuously , from 60 fps till 10 fps and never recovers or might recover in near future , as I observed for 20 minutes but its too much time to wait.
My observations:-
1> I used Time profiler it shows maximum time is in draw() calls. Also if I play game very fast the peak of time increases in track, that should be fine as I am giving more work to do, but once a peak is attained it remains approximately at that height only, even if I leave the game Idle. Is it normal ? According to me it should have returned to its normal peak once the current work is done.
2> Some where I thought its happening because I used two batch nodes and removing its children on a user touch immediately might causing it slow but then after removing the children it should run normal. to give an idea is it ok to remove 10 children from batch node immediately ? some guys say its very slow process. Just to check if this causing problem , I did :-
Instead of removing them I just set visibility of the children to false.But still FPS drops and never recovers.
Please share your thoughts on this.
Though SpriteBatchNodes are generally quite good for drawing a lot of elements efficiently, I think there are best used for static/not-so-dynamic elements. In your case, if you have a lot of elements which go out of the screen but are still alive the draw() function will have to make some checks, thus hogging your performance (even if you set isVisible(false); explicitly, it still nedds to be checked).
In your case I think it would be better if you simply added new shapes outside of screen via some time-based function, and if they scroll outside of view simply remove them from scene, without using batchNodes.
Just found that with every touch, I am adding 8 new sprites to the layer, and its adding every time I touch . So with time I am giving more and more work to do. This is the problem
Actually I wanted to replace the sprite at 8 places with a touch, the way I was doing every time :-
_colorBottom1=CCSprite::createWithSpriteFrameName(png[0]);
this->addChild(_colorBottom1,kForeground);
_colorBottom1->setPosition(ccp((_colorPanelLeftPad)*_blockWidth,_blockWidth));
It was causing this sprite to be added with every touch.
but it should have been (Replace the texture instead of creating the Sprite again):-
CCSpriteFrame *frame1=CCSpriteFrameCache::sharedSpriteFrameCache()->spriteFrameByName(png0);
_colorBottom1->setDisplayFrame(frame1);
I am confused as to how endless runner games actually work, conceptually, as far as having a never-ending canvas. Sprite Kit is under NDA, so I am going to use Cocos2D as my framework.
There are some tutorials on the web that are specific to other languages, and tools, but I just need to figure out basically: If I create a scene with a specific size, how do I create the illusion of a never-ending background? Do I just animated backgrounds behind the scene, or do I somehow dynamically add length to the scene, so my runner really is running along the canvas?
Do I make sense? I just cannot grasp what the actual method these games use is. They certainly feel like the runner sprite is moving along a canvas, but maybe it's just that he's staying still and all the elements are moving?
One way that you can make the "endless" environment is by making UIViews (or NSViews depending on what platforms your game will be available on) that contain only a section of the environment so they can be reused when the runner passes that part of the game. Each view can be dedicated to display a certain feature of the game such as a power-up or an obstacle and it will be up to the logic of your game to decide when to use each view.
Lets think of endless runner like jetpack joyride.
You might want to have two background nodes, each larger than the screen size by some amount (maybe 1.5 or 2 screen widths).
When you load your level, you load first background and add second background at the coordinates where first ends, so that they form long screen. Then when we start moving character along this background when first background leaves screen we can take it, and change its coordinates to those where second background frame ends. This way when this comes to an end, we do the same with it.
This way only using 2 long images we can simulate essentially endless space.
You can use longer sequences for your game.
You can add other nodes to your background when it has left the screen and present it, so it looks different each time.
I am building a cocos2d continuous running ios game, where a character is animated to run through a scene. The background, the grounds under the character's feet and a fence behind the running character move in the opposite direction to simulate forward motion. The character itself is animated to run in place. Occasionally additional sprites move by in the scene.
All my movement (except the in place animation of the character) happens in the update method.
I notice that all the moving parts stutter when additional sprites are moving past the scene. When there are no additional sprites, the stutter goes away.
I also notice that the stutter is almost imperceptible in the ipad 3 (ios 6.0.1), whereas it is most noticeable in the iphone 3gs (ios 6.0.1) and ipad 1 (ios 5.1.1), and moderately noticeable on the iphone 4 (ios 6.0.1).
I have no idea where to begin to address this - I tried removing the actual rendering of the additional sprites, and I also tried removing the fence behind the character - but neither change had any impact on the stutter.
Any suggestions?
Update: fixed it by running time profiler as #Fogmeister suggested below. Turns out I was doing disk i/o on every update to look up some state variables. I optimized that away and the stutter is gone on all devices. Thanks!
You need to identify what is taking up the time in the code and causing the stutter.
It seems like it is just an optimisation issue as you can see more stutter on older, slower devices and less on new more powerful devices.
Analyse the app using the Time Profiler instrument. This will tell you where the time is being spent and point you almost instantly to the function (if not the line) that is taking the time.
Once you've found that you can start optimising.
What is your code for the movement of the sprites? If you are updating the positions manually in the -(void) update:(ccTime) delta {} method make sure you are multiplying each movement by delta to account for any minute framerate fluctuations.