Jump to content
  • Advertisement
Sign in to follow this  
axv4745

Framerate Capping vs. delta time scaling

This topic is 4696 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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,

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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?)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!