Game slightly jerky

[XanthorXIII]

So after building the Main portions for my game, I'm running into slight issues where the game is jerky. The main game play starts up fine but after a bit it jerks a little bit and then goes back to being fine. I've implement MrTAToad's AppTimer which I call once per game loop and pass it to whatever needs it to update their movement. If I set the game to LIMITFPS -1, the game doesn't do this, however if I leave it at the default of 60, the game jerks a bit.
Is it also possible that I may have too many function calls?
I don't need specific answers but just some general guidance on what I should probably avoid or try doing different.

[spacefractal]

Then I'm not alone with this issue, and already posted it about two weeks ago in the bug section.

Also I do 65 update ticks to avoid jerky to with limitfps -1 or limitfps 30.

[MrTAToad]

You should use Limitfps -1 to let things go as fast as possible.  Don't forget that in a multi-tasking environment that there can be the occasional stutter.

Other things could include a bottleneck in the GPS especially with high resolutions.

Try to complete all actions as quickly as possible.

[XanthorXIII]

I'll probably do that then. So do you set it to LIMITFPS -1 and then update the game based on the APP Timer routine?
Thanks.

[Slydog]

Forgive me, I'm not a veteran games programmer, just a programmer.
Why do people limit the FPS to a certain rate?
Isn't it better to just let the game run as fast (or slow!) as it can?

All my speed and movement variables are time based, ie: the bullet moves at 'x' units per second.
Then each frame just figure out how much time (ms) has passed since the last frame (GETTIMER()) to figure out how many units to move this frame.  [distance_this_frame = speed * (ms_since_last_frame / 1000.0) ]

Then if the device is fast enough to support 60 FPS then it will, but a slower device will automatically run smoothly at 34 FPS.

I can see maybe to match the device's refresh rate, but that would only be good if it matched exactly each frame (or am I wrong?).
Or, you find the game play varies on different speed devices, such as a faster device detects input more frequently allowing the player an advantage to move quicker, or something.
[Edit] Or to make the code cleaner, since you only need speed to be units per frame?

And to your original question, I wonder if it is jerky whenever that frame exceeds the 60FPS limit and the code is playing 'catch up' or something (or a timing/FPS bug when this occurs?).  The device not being able to meet the desired FPS (for a moment or so) and may accumulate the extra ms difference, and not discard extra ms when it exceeds the limit.  I don't know the code so I'm just guessing.

[MrTAToad]

So do you set it to LIMITFPS -1 and then update the game based on the APP Timer routine?

Thats how I do it in Spots!

Why do people limit the FPS to a certain rate?

The idea being is that they are hoping that the program will run at (or as close to as possible) the given rate.  Unforunately multi-tasking systems have a nasty habit of taking control, thus causing jumps and what not.

The other hope is that the program will run at the same speed on different processors and platforms.  Unfortunately, this too is wishing for slightly too much too - some processors may not be able to reach the FPS and some reach it...

As movement should run at the same speed on all platforms and configurations, you do need to be able to take absolute control over the movement, hence a calcuation is needed between the time of one frame and the next.  You could limit the fps and still use a timer, but why lose all that available speed and time ?

Note that my AppTimer does have one flaw, and that is if there is a long pause between one frame and the name, it will result in a large delta value for one frame.  It could be sorted by averaging over, say 5 frames, but I've never bothered to add it... 

The really proper way of doing it would be fixed time steps where do you do your updates in one tick and then interpolate all movements and animations.

http://gamedev.stackexchange.com/questions/1589/fixed-time-step-vs-variable-time-step takes about the different types (although mentions them to do with physics).

[XanthorXIII]

Cool. That really answers my question. I think for the next game I may try to focus a little more on the piece that you suggested however for this one, the game is not that complicated that this would cause any problems. I'll have to see how it runs on other devices but this should be no problem.
Thanks!

[Wampus]

Thanks. Finally taking this on board.

In the most popular post on the page MrTAToad linked to there is a section of links under the heading notes. They're very useful. This little article linked here explains fixed time steps very well, for example.

[MrTAToad]

Yes, that site is pretty good