I am trying to make my games framerate independent and of course i was referred to Time.deltaTime.
What I understand is that deltaTime will give me the time that the last render has taken, therefore making me able to adjust changes based on the time passed.
What i need to know though, is if this “passed time” is actual, real world time or physics simulation time or maybe even the amount of expected update cycles per second or any variation of these.
Here is why i do not understand it / need to know more about this:
People always describe that 60fps would give you the same movement speed as 200fps if the fps fluctuate. Thats fine.
But as a simple example, imagine a game where you are a bird and you may flap your wings only once every second. To make that one second regardless of my target platform (might be 60fps or 120 for example), I would use deltaTime.
Now you open up some CPU intensive program in the background and your fps plummet to 1fps. Of course when I can only display 1 frame each second, i expect the physics and everything to run slower as well, or else it would turn merely annoying stuttering into unplayable game jumps, as i cannot be expected to react to a game world that runs at “real time” while I can see only one frame per second of it.
If deltaTime delivers “The time in seconds it took to complete the last frame”, as stated in the documentation, would that not mean that my bird can now flap its wings every frame, which might be only a fragment of a second in physics time? Would that not allow me to cheat by slowing down my computer? And would that not break any game most of the time when the framerate drops below playable values?
While writing this I realized what I would like to get from deltaTime is the amount of physically simulated time since the last call to update. So is it that what it gives me, or is it the actual time since the last render, which would be kind of strange for the reason described above?
