Understanding Delta Time
In this article we will look at understanding delta time, a concept I know from experience, can be difficult for beginners.
Delta time, or also referred to as elapsed time is usually a value that is calculated for us within modern game engines such as Unity or Unreal. Delta time describes the time difference between the previous frame that was drawn and the current frame.
Note: A frame refers to the image we see on the screen, which gets updated a certain number of times a second. The frequency in which the frame is updated is known as frame rate, usually measured in frames per second (fps).
In the above image, three frames of a game are shown, in which, in each frame, some amount of time has passed between them. The passage of time can be seen by the objects in the game having moved or rotated. The time that has passed since the previous frame and current frames are stored in delta time.
This all makes sense you say, but why do we even need delta time in the first place? Well, to answer that question, we first need to know a little about how games work.
If you read my article on frame rate or have some understanding of how video games work, then you will know that a game is essentially one giant loop that is constantly being run until the game is stopped. In each iteration of this loop, a new frame is drawn.
The number of times the loop runs, and thus the number of frames drawn each second, will vary dependent on the hardware the game is running on because not all hardware is created equally.
How the CPU Affects our Game
The code of our game will be executed by the CPU of the device. Our code is compiled (converted) into machine-level instructions. The speed of a CPU is determined by how many of these instructions it can execute in a second, known as its clock speed, measured in gigahertz (GHz).
A CPU that has a clock speed of 3GHz can execute 3,000,000,000 clock cycles per second, which amounts to the execution of around 3,000,000,000 instructions (some instructions can take more than one clock cycle to process). Another CPU might only have a clock speed of 2.6GHz meaning that it cannot execute as many instructions.
What all this means for our game is that a game will run at different speeds dependent on the CPU in the device, and that is okay. This is common in many triple-A games. A game we play on PC might be able to run at 60fps or more, whereas on console that same game might be capped at 30fps just because a console isn’t as powerful as some PCs. What isn’t okay, is if the game we have developed is frame rate dependent.
Why Frame Rate Dependency is Bad
A game that is frame rate dependent is one in which parts of the game is tied specifically to the number of frames the device the game is running on can draw.
Let’s look at one area in a game which shouldn’t be frame rate dependent, movement. When we are describing movement it’s in terms of the distance we travel over some specified time, like meters per second (m/s), or miles per hour (mph). If our game is frame rate dependent, then the speed at which our objects move is tied to the frame rate which means the speed of our game objects will be different on different hardware.
Assuming we have a spaceship and we want it to move at 10m/s (yes it’s a slow ship but I cannot draw people and I didn’t want to complicate things by using units other than seconds) then if we knew our game ran at 30fps on our device then we would want it to move at 0.33333 meters per frame.
However, as soon as we run our game on a different device then the speed at which our ship moves will no longer be at 10m/s. On a device that can run our game at 60fps, we would have moved 20m/s. This is because we would be moving at 0.33333 meters per frame, but our game is now running at 60 frames per second.
But we Can Just Cap the Frame rate, Right?
You might be thinking that we could simply cap the frame rate at which our game runs at. Although that would work in theory, in practice it often won’t solve the problem and has certain limitations.
Although we can limit how many frames are drawn each second, we don’t have control over how long it takes the CPU to draw each frame. Thermal throttling or simply having too much to process in the game at a certain time can result in a frame, or several frames taking longer to draw than usual. If we don’t hit our frame rate per second goal, then we are back to square one with our movement moving slower or faster than we would want.
Secondly, limiting the frame rate means that devices that can run at higher frame rates are capped from being able to do so based on a technical limitation of the game and not the hardware. Higher frame rates often lead to a “smoother” feeling experience when playing games, and it would be a shame not to have that due to our game being frame rate dependent.
Therefore, if frame rate dependency is bad, and we cannot simply cap our game to run at a specific frame rate then we must turn to something else. Delta time.
Delta Time to the Rescue
Delta time is the solution to solving our problem, freeing our code from the frame rate, making it frame rate independent.
How using delta time does this is quite simple. If we first look at the problem of running our game on different hardware devices that run the game at different frames per second. If we still want our spaceship to fly at 10m/s but we want it to run on devices that can handle both 30 and 60fps. Then all we need to do each frame is multiply our game speed by the delta time (measured in seconds) value. Below is some code showing how the spaceship can be moved in the positive x-axis by 10m/s using delta time.
private float _speed = 10; //m/s
private void Update()
{
transform.Translate(new Vector3(1.0f * Time.deltaTime * _speed,
0.0f, 0.0f));
}Now, at 30fps the delta time value will be 0.033333 seconds so each frame we update our ship by 10 meters per second multiplied by delta time.
Notice, we get the same value as before. What is different, is that if our game is running at 60fps then the delta time will be at 0.016666.
In either case, using delta time, the difference in time between the last and the current frame gives us the same speed value. It doesn’t matter what our frame rate was, it would still result in the spaceship moving at 10m/s. This is achieved by multiplying the speed value by delta time to either speed up or slow down the distance we move that frame dependent upon how big or small delta time is.
The reason why this works is that our movement is no longer tied directly to the number of frames drawn each second, which is the number of times our game loop runs. Instead, with delta time the movement of the spaceship is now updated based on the amount of time that has passed which is what we want as we care about distance travelled over some length of time.
This even works when the framerate is not stable, i.e. some frames are drawn quicker or slower. If a game fluctuated between 60 and 55fps then we would still be moving at 10m/s but that movement might be done over fewer frames e.g. 57.5 frames as some of them are taking more time to draw than others. This is fine, we don’t want our movement tied to our frame rate so as long as we still move at 10m/s we should be happy, even if it takes fewer frames than what we are aiming for our game to run at.
When to Use Delta Time
The last thing I wanted to talk about in this article was when to use delta time in our games. We have already seen that it’s important to use when moving characters and it can be extended to other types of movement, such as rotation. In general, delta time should be used when something we are doing needs to be frame rate independent.
In contrast, most of the code we write won’t need to be done over some specified time. Often, we would want our code to run as fast as possible, or certain parts of our game won’t run in our game loop at all and will only be called infrequently when certain events occur.
Finally, when dealing with physics, such as applying forces to rigid bodies, delta time should be avoided as the physics system in-game engines rely on a fixed time step. However, this is a conversation for another time.
To summaries, delta time is usually a variable calculated for us in modern game engines that stores the time difference between the last and current frame. This value should be used when dealing with parts of our code that need to run independently of the frame rate. Where something needs to be done over some specified amount of time, such as travelling a certain distance a second.
Like always if you have any questions then feel free to message me @gamedevunboxed :)
