# Is Time.deltaTime the last frame time or it is the time difference between frames?

I just came across the unity blog and found that unity 2020.2 trying to fix Time.deltaTime which is good for more smooth movement (correct me if I am wrong). But when I am reading the blog I found this thing:

In layman’s terms, delta time is the amount of time your last frame took to complete.

Then, i realized i don't know what exactly the delta time is because i was thing that it actually the difference between the two frame. Then, i consult the unity docs again and find this thing

The completion time in seconds since the last frame (Read Only).


the second line telling something different (isn't it?) which i am thinking is the defination of deltaTime

This property provides the time between the current and previous frame.


I try to understand it through an example: time - difference:

4

5 (1)

6 (1)

6 (0)

5 (1)

3 (2)

If you see the above what will be the delta time?

• I think the confusion comes from what they call "last". Sometimes last means current frame, sometimes it means the frame before the current (i.e. previous). But deltaTime always means the time between current and current-1, i.e. previous to current. Commented Oct 6, 2020 at 9:17

This property provides the time between the current and previous frame.

That definition is correct. We can argue that it could be clearer.

In layman’s terms, delta time is the amount of time your last frame took to complete.

That is an over-simplification.

After looking for the article in question… I can see the break it down very well afterwards.

First of all, delta is NOT a difference between how much frames took to complete. That is not at all the case. If it where, it would not be useful for physic simulations.

Imagine a floor tiling. If you measure the length of a tile, then the length of another tile, and then take the difference… THAT IS NOT DELTA. Delta is not a deviation.

Instead, delta is closer to a measure of length of the tile, but not quite.

Delta is the measure from the start of a tile to the start of the next.

That is a very good approximation of the length of a tile. And we can - for most purposes - pretend it is a measure of the length of a tile. In reality, that isn't a measure of the length of a tile. Because there is a gap between tiles.

Going back to game engines. The usual approach is the following:

1. Take the time from the prior cycle.
2. Take the current time.
3. Compute the difference. That difference is your delta time.

Make sure that the time you took this cycle is available on the next one, so store it on a variable outside the cycle.

Taking the naive example from the article in question:

var time = GetTime();
while (true)
{
var lastTime = time;
time = GetTime();
var deltaTime = time – lastTime;
ProcessInput();
Update(deltaTime);
Render(deltaTime);
}


Please, read the code, it tells you what deltaTime is better than anything else.

Note: We want a high resolution monotone time, when available. See how to measure time.

Game engines take the name "delta" from math. In math "∆" (Capital Greek letter Delta) means increment or change in a variable. In this case, the variable is time (not duration).

Here is the deal: There are other things the engine does every cycle aside from calling Update/Render. In the example above, we see it also processes input, and that takes some time. There is a gap between the tiles. There is time used for things other than running Update/Render.

Do not take deltaTime as a measure of the time your code took to run. If you want that, measure it yourself, with a profiler if possible. Much less as a deviation of how much your code took to run. To reiterate, deltaTime is not a deviation.

The practical takeaways is that deltaTime as the time the engine is asking you to simulate. Why is the engine asking you to simulate that amount of time? Because it has measured that is how much it takes for a game loop cycle, and we expect them to be stable.

You would be simulating more time than your code should take to run. In doing so, movement should appear smooth. Because it accounts for the time time engine takes to do other things.

The engine, can - of course - do better than the naive code I posted above. The article in question is, in fact, dedicated to how they improved it in Unity.

Not really different, you are getting confused by the English language nuances. The Delta Time is the time that the very last frame took to complete, from start to finish. The idea is that every frame will take the same time (or so) therefore, it can be used to compute a movement/rotation in terms of a single frame.

As you might suspect, this is not an exact science because on the current frame you might do something entirely different compared to the last one, and that is what translates into lags or twitches in movement/rotation of objects.

It might be possible to add more intelligence in it, resulting in computing the Adjusted Delta Time, but the adjustment itself takes away precious nanoseconds especially on a game that must run at a high frame-rate, which is why we all end up using the basic Delta Time, giving up the adjustment.