Framerate Capping vs. delta time scaling

Started by
3 comments, last by Flimflam 18 years, 3 months ago
I've been recently reading several articles that talk about games that use frame rate capping techniques. For the all the games I've written I've never dealt with frame rate capping but I've always just scaled all my important values (movement, animation, etc...) by the delta time between ticks of my game-timer and this has worked well for me. To me this seems pretty straightforward and makes sense and thus I see no reason to wanting to cap frame rate when you could just scale you're values by delta time. I know I'm probably way off the ball here. Could anyone offer any insight as to why you'd want to do framerate capping as opposed to just scaling everything in your game by the delta time of you game-timer ticks? thanks,
Advertisement
framerate capping makes it easier to syncronize multiplayer games for RTS's that rely on simulation syncronicity. i.e. each client has it's own instanced AI that's making deterministic random rolls on each machine. you avoid extra network traffic for AI moves and make all clients have the same CPU load (i.e. don't need a "server" that's doing all the AI updates). With a capped framerate it's easier to keep everyone in lock-step so that the simulations stay in sync.

-me
Another option is to not necessarily cap the 'frame rate' (rendering), but instead run the other bits (physics, input, etc) at a fixed rate while letting the rendering go as fast as possible.

A method of achieving this is explain here: http://www.gaffer.org/articles/Timestep.html

There are probably many other ways to do it though.

The reasoning behind running the physics/input at a fixed value is because the numerical integration can become unstable (and possibly explode) if the deltaTime varies wildly, or strays too far towards low fps. With a fixed timestep the same input should always produce the exact same outcome everytime. (I suppose in theory?)
If you're using physical simulation (ODE, Novodex, etc) then a variable timestep will lead to instability in resting bodies. A fixed timestep is much preferrable in such systems.

The Canonical Game Loop talks about how to run physics and input at a fixed rate, while running graphics at a faster or slower rate depending on machine resources.
enum Bool { True, False, FileNotFound };
In my experiance, capping the frame rate in whatever way also guarantees things won't nessisarily spike. I used to always have issues using delta time to move characters, they wouldn't move fluidly smooth, despite there not being much going on. In 3D games, this isn't noticed as much as 2D games (I used to write a lot of 2D RPG engines)

Capping the frame rate, (I basicly just turn on vsync and set the refresh rate to 60hz) I can guarantee that things wont jump, and using loops are a little more lax.

Other than that, I dunno. To each his own.

This topic is closed to new replies.

Advertisement