TIGSource Forums

Hey, I've got a quick question about FPS that's been bothering me for a bit now.

In games I usually do it the game loop way in that it checks for the current time and time elapsed since last frame and all that and then draws/updates if the conditions for a new frame are met.

However, another method, that I've also seen quite a lot, is to save the FPS in a constant somewhere and then, whenever something is moved (like character movement or gravity) the thing is divided by the FPS. This of course requires much higher values for gravity and the likes.

The question now: Is there any benefit over using either method or is this really just preference? The latter method always seemed a bit more prone to bugs to me (like when you forget to divide at a point or another) but maybe I missed some other advantage in turn.

It's a surprisingly complex topic with more viable options than you have listed, but a direct response to your question is: If you ever want to change the frame rate later, the first technique will be a mess. Also, the second technique lets you specify velocities as distance-per-second, which is generally easier for humans to imagine than distance-per-small-fraction-of-a-second.

EDIT: And if you ever decide to implement bullet time, a slight variation on the second technique would be very useful.

I don't understand.
I have a fixed FPS and I check for time elapsed. Is that two different approaches?

I have velocities as distance/frame because I've got a pixel perfect platform game where the animations match up exactly with the movement.

The second technique allows for computers that are having trouble keeping up with the frame rate of your application. With that they can run in real time, but at a lower frame rate. There will be small differences in certain calculations, so the result is slightly less deterministic, so it's really down to how you want to do it and what the requirements are (e.g. for a networked game, a fixed timestep might be better?)

I started out my game with the second approach, precisely because I worried about the game running on slower systems and because I wanted my velocities to be distance-per-second. However, it did present its own unique challenges.

I was using some rather simple collision detection, which checked for collisions once per frame. After introducing some calls to sleep to slow down the game by 20%, I noticed that a lot of objects were passing through each other. In the end, I had to implement swept collisions, which ended up being slower and slowed down the game on slower computers even more.

I also needed my game's animations to be the same no matter how fast it was running. This meant skipping frames of animation occasionally, and was rather jarring visually.

Finally, when I decided to use a physics engine, the physics engine stated that using a fixed timestep would yield faster and more accurate results. At that point, I decided to switch to a fixed FPS.

I generally try to decouple rendering and update (physics, game logic).  Rendering runs as fast as possible, and update runs at a fixed rate.  If the frame rate is low, I'll do multiple updates until the game is caught up before rendering the scene.  You can end up in a "death spiral" (never catching up to your fixed frame rate) if your update is slow.  At this point I usually add a hard cap on the number of updates (2 or 4 or whatever) per frame.  At that point you'll have some slowdown though. 

One nice thing about this is if you're running faster than your fixed frame rate you're rendering more than one frame per update.  You can use the actual frame time for updating purely visual effects in a smoother way.  This can be generalized into having a generic fixed update and generic variable time update.

http://www.flipcode.com/archives/Main_Loop_with_Fixed_Time_Steps.shtml (http://www.flipcode.com/archives/Main_Loop_with_Fixed_Time_Steps.shtml) has a better overview.