Delta Time - The Road to Frame Rate Independence - Daniel's Blog

# Delta Time – The Road to Frame Rate Independence

The word “delta” can be defined as the difference between two things or values. This was a word I first came across through physics, with delta(represented by a triangle) describing the change in a certain value. So from there, we can draw the conclusion that delta time is the change in time. In game development terms, it’d specifically represent the time that passes between each frame drawn.

## Why do we need delta time?

Delta time allows us to achieve what is known as “frame rate independence”. That means,
regardless of how low or high your framerate is, the rate at which things occur
or are updated(for example, the change in object positions according to
velocity, the rate at which an object’s velocity increases) remains consistent
throughout the game.

For example, if we were to be updating a flying object’s position by a velocity of 20 pixels per second toward the north, having frame rate independence would help us ensure that regardless of whether we’re getting 30 frames per second on one computer or 60 frames per second on another, the position of that flying object on both computers would remain the same after each second.

## How do we implement it?

Let’s continue building off of the example that we used above. Our goal is to update an object’s position so that they move 20 pixels toward the north every second.

First things first, let’s take delta time. This can be done by dividing 1 by the player’s frame rate, giving us the time between each frame(let’s say that value is 1/60 because the player’s frame rate is 60fps, do take note that in the real code implementation you won’t know what the frame rate is, you need to take the frame rate with whatever function your library or your engine supports).

Now, we multiply the velocity of 20 pixels per second to the north by delta time, which reduces the velocity so that after 60 frames, i.e a full second, the object’s position would have moved by approximately 20 pixels towards the north.

In this case, our object’s position would be updated by 0.3333 pixels towards the north every frame. So by the end of 60 frames, our object would have moved by 0.3333 * 60 = 19.998 pixels toward the north.

Below you’ll find the full representation of this process in pseudocode.

`player_frame_rate = get_fps()delta_time = 1/player_frame_ratevelocity = Vector2.new(0, 20)object.y += velocity.y * delta_time`

Alternatively, you can just divide the velocity by the frame rate because

`y * 1/60 = y/60`

Let’s say our game was being run on a lower-end computer and we were getting 30 frames per second. Let’s step through our code and see what happens. Intuitively, we know that if we’re getting only 30 frames per second, our object will have to move faster each frame compared to when we had higher frame rates. This is because we have less frames to display the journey of the object’s position to our target destination, and therefore we need to increase the distance our object moves each frame. Let’s check if our code does end up following that trend.

First, with a frame rate of 30 fps, our delta time will now be 1/30. When we multiply 1/30 by our velocity of 20 pixels to the north, we get 1/30 * 20 = 0.6666 pixels toward the north every frame. That’s double the velocity we had previously with 60 frames per second.

We now know that our code works and it indeed follows the inversely proportional trend between frame rate and update speed.