# What is framerate-independent motion?

What is the definition of framerate-independent motion and why is important to have it in games?

Framerate independent motion is when objects in your game move based on some criteria other than which rendering frame you are on. Typically this alternate criteria is the delta time since the last update.

A game loop that is framerate-dependant might look like this:

while(!done) {
// update all objects:
foreach (object in objects) {
object.position += object.velocity;
}

// ...rendering, et cetera...
}


In this loop, if your game runs at 60 frames per second, every object is also updated 60 times per second. However, if your framerate increases or decreases, the rate at which objects update increases or decreases as well. Typically this is undesirable because the wall-clock time (that is, real time) is still exactly the same, so the user perceives the game objects moving much slower or much faster.

Old games typically did this, which is why if you try to run some of those older games on modern CPUs (even under emulation), they run way too fast to be playable, because your modern CPU can execute many more instructions per second.

By contrast, a framerate-independent loop which relies on delta time might look like this:

previous_time = get_current_time();
while(!done) {
current_time = get_current_time()
delta_time = current_time - previous_time;
// update all objects:
foreach (object in objects) {
object.position += object.velocity * delta_time;
}

previous_time = current_time;

// ...rendering, et cetera...
}


In the above example, the actual real time between successive updates is computed and used to scale the updates, which results in more correct update rates even if your frame rate changes. Generally this is a more desirable way to write your update loop. Not only does correct for disparity in update rates, it also lets you do interesting tricks like scale the delta_time (or set it to 0) to implement time-slowing effects (or pause the game logic).

Note that in practice one may want to set up multiple such timers (especially if you are going to make use of time scaling and want some objects to be unaffected by scaling).

Finally, it's occasionally desirable (especially for physics) to fix your time step.

If you would have your update and draw calls in the same loop, the draw performance would influence the update performance. Therefore you would not have framerate independent motion.

Lets say you have a pc with a really great graphics card and would be able to render @60fps, while your opponent would only have 30fps. Your machine would update your position, shots fired etc @60 times per second, while you opponent only 30.

This would give you substantional benefits.

• thanks for the answer. I thought if u just decrease your fps, it just not smooth as 60fps, meaning 30 fps would have jumping or lag type of motion? from my understanding 30fps would have delay than 60fps? – Dyrus QTPie Feb 11 '14 at 19:50
• It's always smoother and better to have your draw loop @60fps, however, your update loop doesn't have to be this fast. Also on slower machines it might not even be possible (depending on the type of game etc) Also, 30 fps on my machine doesn't have to be exactly the same as on your machine. This depends on the clock cycle of the cpu. – Thomas Feb 11 '14 at 20:09