I am writing a 2D game engine for fun. I am able to perform animation using the engine. However, if I change the frame rate (frames per second) the speed of the animation changes.

I have never used any game engine. I want to know whether other game engines handle this issue or not. If not, what is the ideal frame rate for a 2D game?


3 Answers 3


No, frame rate should not affect the speed - the gameplay will hinge entirely on their video performance, which is disastrous (even if you limit the speed, you can't control people whose systems will run the game at half speed).

You're experiencing this problem because you did something wrong: Your update/render routines run one after the other as fast as possible, with objects updating on a per-call basis (thus when the call speed deviates, so does theirs).

A time-based approach

The correct way to do this is to update objects on a per-second basis.

Consider a bullet for instance: Right now it probably knows how much it needs to move per frame. You need to turn this into how much it moves per second. How you do that is actually not too complicated.

First, your bullet's going to be updated more than once per second, so we need to actually update it every few milliseconds. Each time you update your physics engine, a certain number of milliseconds have passed since the last update: this is called the delta time, normally dt for short. The dt is determined before updating all objects, then all objects update using the same dt in order to keep in synch. The dt is generally passed as an argument to each object in its update call.

In fixed-step physics, the dt is a fixed number, whereas in variable-step physics, the dt varies depending on the actual amount of time since the last update (hence their names).

That brings us back to your bullet. It's been told to update with a dt of 16 milliseconds, for a physics engine updated 60 times per second: if the bullet moves 12 metres per second, you move it (16.0/1000.0) * 12.0 metres in this update.

  • 4
    \$\begingroup\$ This approach is not ideal for numerous reasons. Gameplay will be non-deterministic, making multiplayer syncing much harder than it should be. If the update rate slows down enough, objects could tunnel through barriers, or collisions that should happen could be skipped over. \$\endgroup\$ Jun 15, 2011 at 20:10
  • \$\begingroup\$ That is why the time passed (dt) can be clamped, meaning from frames per second 5 - 1000, your engine works correctly. Below 5fps, you will get a slowing of time (ie the dt is clamped). \$\endgroup\$ Jun 15, 2011 at 21:00
  • \$\begingroup\$ @Daniel, It is still non-deterministic, making synced network simulations, or a replay system much more difficult to implement. And if you were to create a Rube Goldberg type puzzle game, after a few seconds the simulation will not replay the same way each time. \$\endgroup\$ Jun 16, 2011 at 16:00
  • \$\begingroup\$ Ah, for some reason I thought he was using a fixed time step with dt stepping... So yoir right, this is bad. \$\endgroup\$ Jun 16, 2011 at 21:58
  • 5
    \$\begingroup\$ To be fair, this approach is more than good enough for anything not performing complex physics, and has worked in many shipped games. So it's best not to get too worried about needing the fixed time step and interpolated rendering, etc. \$\endgroup\$
    – Kylotan
    Jun 17, 2011 at 11:19

The best way to make your game run the same speed on all systems is to use a Fixed Timestep.

With a fixed timestep, the game will always update at the same rate, no matter what the render rate is, and when using interpolation, it will look smooth even when the render rate is much higher than the update rate.

Here is an answer with resources on how to implement a fixed timestep.
Semi-fixed or Fully-fixed timestep?

Here is an answer that explains how to implement interpolation for movement and transformations.
How to Interpolate between two game states?


No it should not. One type of timing you can do in your game is frame-based timing. The idea is to let the game loop run as fast as your computer can run it thereby having the bast overall experience and you control the rate at which your simulation runs. Now you've decoupled your updating from rendering and have precise control over it.

In this scenario, your game loop can be running at say 60 fps on one machine and maybe 45 or something different on another, but your simulation will always run at the precise specified rate between them.

You game now is divided into two section, one to render your graphics and the other to updating your simulation. You set your desired simulation rate at game start and at the top of your game loop, you get the elapsed time. Note, this elapsed time is a time quantity based on your desired simulation rate. This value is then used as a multiplier against your game objects to keep them moving at/or very close to your desired simulation rate. For example, if you want your simulation to update at 30 fps and your game loop is currently running at 60 fps, the elapsed time value for this frame will be 0.5. When you multiply this by the speed of your moving objects it will cause them to move at 30 fps. Know that from frame to frame your game loop speed will vary greatly and frame base timing can keep your simulation running at a known and predictable rate.

The result is silky smooth animation.

  • 1
    \$\begingroup\$ -1 This is just fixed-step updates (as explained in my answer and AttackingHobo's), except does things at a rate of per-frame rather than any intuitive measure like per-second. If you're going to go this far, it's only a small step toward doing things on a per-second basis and saving yourself all the unintuitive mental arithmetic translating between per-second speeds and per-frame speeds (and making everything far simpler if you happen to change your frame rate). \$\endgroup\$ Apr 26, 2012 at 8:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .