TIMESTEPS and DELTA TIME | Game Engine series

Gear I use:
-----------------

[venumspyder]

You can also update your game state at a FIXED time step very much like a physics engine. This will give you consistent updates as well as reproducible results if you are debugging certain types of time related issues. With a simple time step, if your frame rate drops to 30 fps you will miss frame updates which could lead to problems and gives inconsistent game updates. Now if you update the game at a FIXED time step, the game updates independent of the frame rate. So if you update at a fixed time step of 60 fps, and the frame rate drops to 30 fps, then for that frame you will update the game state TWICE (fixed time step is (1/ 60)). This depending on implementation and update rate will create choppy or stuttering as characters move through the game. One solution (which I have seen in many games) is they update at a very high time step (say 1/120) so that the time interval is very small and this reduces the stuttering. I save the previous position and current position of an object and then use that to interpolate what is displayed on the screen between fixed time step intervals. This eliminates any stuttering and I don't have to update at such a high fixed time step but introduces some very slight lag with what is displayed on screen.
If anyone is interested in researching this further google: Fix Your Time Step.

[RitobanRoyChowdhury]

One critical thing that I think you missed is that adding delta time is a problem if you need exact reproducibility from a certain game state. If you're running at 30 FPS, as opposed to 60 FPS, not only is it not being rendered at those in-between frames, but calculations are also not happening. At low framerates, this can lead to artifacts like teleporting through walls, or even more minor things, like rounding errors compounding over time. While this won't matter for most games, like FPS, it does matter for some situations. If you're writing a physics simulation, reproducibility is probably more important than looking roughly the same regardless of framerate. Similarly, factorio doesn't implement this, instead choosing to slow the entire game down, for this reason -- it's really important that from a certain game state, you can find the game state at some point in the future, regardless of what system your on. This is how it manages it's multiplayer, where it just has the input being sent to all the players, so every player can independently run the game, yet still know that their copy is the same as everyone else's.

[trapido]

3 videos, one week. God damn your good! Keep it up!

[regbot]

Exactly what i was looking for. Again, Thanks cherno for these videos. I really like these quick explanations, with like school board and stuff. You are good a teacher.

[arini]

Thank you! I was looking for a mathematical explanation for this. Now it makes sense.

[Tremah]

You're just so good at explaining things.
Thanks for the incredible amount of content you put out!

[marcklein]

Great video. For camera movement this variable time step is fine but if you use it for physics your calculations will get non deterministic. That's why in that case a fixed time step would be better.

[giladreich]

Very informative video! Thank you for the extra uploads this week, much appreciated! :)

[fenril]

I wonder if the method of locking the Update callback to 60 executions per second that you mentioned, is akin to the notorious Physics issues in Bethesda's games. It's been a long standing issue with their games built with the Creation Engine (and it's previous incarnations), to have tons of physics bugs when the game runs significantly faster than 60 fps.

[zxuiji]

I was just thinking, the fps restraint can double as velocity e.g:
pos += (global_fps * object_fps.current * move_distance);
object_fps -= (object_fps.current - object_fps.restrain) ? object_fps.revert : 0;
Might actually give a natural blur effect like you see films depict superman & the flash as being when they move.

[Rob......]

What about the impact from external sources e.g. system interrupts? How do game studios control things here so that the OS/etc doesn't cause stutters etc?

[usero]

Just a quick thought:
If you feed this delta time to every moving object in a scene like characters, particles, cameras and etc., in theory, you should be able to create a slow motion effect by gradually tuning the delta time down and up at specific times of your game, right?

[jdp_man]

i might actually use this since ive been watching you create it

[dacracking]

so the movement is consistent even if your framerate fluctuates.

[daniel_]

what about acceleration? how do I make that not depend on the frame rate? is it the same case of just multiplying by delta time?

[diligencehumility]

Would you gain any performance from running the game loop in the GPU instead?

[diligencehumility]

I don't understand how setting glfw swap interval (vsync) on/off would effect your update rate? Your update rate will run at max no matter what, you only limit the amount of frames drawn to 60 with vsync, right?

[artyombabich]

i assume you know your time step of the last frame and applying this value to some action in the current one. But can you actually know your timestep of the current frame and apply this value to actions?

[pastasawce]

Im having problems with box2d objects moving VERY slowly with vsync on

[nauq]

The VSync doesn't work with me :(