Since it calculates the time since the last frame is it always one frame behind?
Yes it is, but then how could it ever know the time to complete the current frame until its finished?
“The time in seconds it took to complete the last frame (Read Only).”
Yeah i kind of figured. One question i’ve been pondering on is say your computer is running at 30fps and then next frame it goes down to 20fps i don’t understand how Time.deltaTime can move in proportion to lets say 50m per second when the time between each frame differs greatly.
it doesn’t have to “move in proportion” it just needs to count the time it took to process that last frame.
0.0001 seconds or 0.01 seconds or whatever it is.
So what is the point of saying a object will move 50m per second rather than per frame.
I’m not sure what your point is in asking the question though. What are you trying to achieve?
Could you be wondering about “Fixed/Constant Timestep vs Variable Timestep”?
This is basic and fundamental gamedev stuff. Try googling it if it interests you.
Unity uses both and gives you access to both (as any modern engine does).
This is why there’s FixedUpdate and Update.
And also Time.deltaTime and Time.fixedDeltaTime.
The delta times are “behind” but it is exactly what you need to update your game logic state to represent “now”.
This is also the realm of discrete vs continuous/integrated calculations. Academically, it does require some Calculus to really understand, but really, you only need to draw out a timeline on paper or something to get a feel for the implications. Either way, it’s an intellectual exercise that’s arguably unnecessary if you’re not planning to develop an engine’s guts.
Your question is may be about reliability. If it is, you’re right, deltaTime itself can tend to be unreliable since framerates are reliably never constant down to the millisecond.
In that case, your game-relevant logic should rely on FixedUpdate and fixedDeltaTime. These game loop logic elements allow you to be framerate independent: it will give you consistent, deterministic results regardless of framerate.
That is not what i was implying but whatever.
If you’re running at 60fps and the object moves 50m per frame the object would move 3,000m in a second. If you’re running at 60fps and the object moves 50m per second the object would move 50m. Big difference there.
1 Like
It’s irrelevant that it’s one frame behind as the whole simulation is one frame behind.
So in what problem was the question relevant?
I assume you know the physics formula:
displacement = velocity x time
Where displacement and velocity could be in any realm that involves change, like a change in rotation, or in color.
deltaTime is the factor you multiply to velocity. It’s what tells you how much time just passed by so you know how much something would have moved in that span of time, given a velocity.
Basing all calculations on the previous ticks data is pretty standard in discrete simulations. It works, don’t worry about it.
1 Like
Ok i get it, that was the answer i was expecting.