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:
- Take the time from the prior cycle.
- Take the current time.
- 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.
