# Framerate independence

I'm building a physics engine in OpenGL, and I'm a little bit confused on how framerate independence is achieved.

At the moment I'm using glutTimerFunc to cap the framerate at 30 FPS. Is there a way to do this without capping it but not have my objects running around like crazy when I run the application at a higher framerate?

I'm thinking that I need some sort of measure of distance relative to the rendering speed. Are there any articles/tutorials you may know that would help me out?

You have to measure the time that elapsed between two frames, and multiply that with every movement calculation that you do.

Computer A runs the game at 22FPS. Computer B runs it at 35FPS.

Therefor, the average time between frames on computer A is about 45ms, and the average time between frames on Computer B is about 28ms.

Now let's say you move players on both of the computers in one direction every frame, depending on the time elapsed between the frames:

On Computer A:

//let t bet the time between frames
player.move(t)


The same on Computer B:

//let t bet the time between frames
player.move(t)


On Computer A, the function will (on average) get called 22 times, and t will have a value of 45.

On Computer B, the function will be called 35 times, and t will have an average value of 28.

Therefor, after one second, the player on computer A will have moved 22*45 = 990 units. On computer B, the player will have moved 35*28= 980 units.

The difference in here is there because I rounded the numbers of milliseconds between frames on both computers. Usually, it will be exactly the same.

• I think Heishe has nailed the solution, but I would like to mention this article explaining with code how you can achieve this starting out from your situation (a locked framerate) and working to the technique mentioned in this answer and beyond (variable framerate with stable physics). – ghost Jun 11 '11 at 11:04

This Gaffer on Games article will explain more than you ever need to know. (great article on timesteps)

At a very simple level, you want to calculate how long since the last frame and use that in your movement calculations. If you attempt to cap it at, say, 60fps, you're not going to be able to check every 16.6666ms exactly. You may end up with an update call at 16.7 ms after the last frame. You multiply your velocity vectors by 0.0167 or whatever and move the object.

If you ran it on a slow computer, maybe getting only 10 fps - so one update per 100ms, you would instead multiply the velocity by 0.1 - the objects may be jerkier, but they will move at the same speed. The last code example in the article shows how to do this (it's very simple).

Also check out:
Frame Independent Movement (duplicate?)
Time based vs frame based
Fixed step vs variable step