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.
This. Fixed timestep with interpolated rendering is absolutely the best way to structure your main loop. Every other method has issues. Too many people are fooled into using delta time in their gameplay code, when it's actually a complete waste of time if you want high precision deterministic gameplay.
Came to the comments section looking for this. I think the reason Yan didn't do it like that is because he hasn't created an entity component system yet. I'm hoping he'll build an alternate timestep system as you suggested in the future once he does set up an ECS, if not replace this method implementation entirely. I'd also like to add, to avoid misinterpretations, that this suggestion is not the same as what Yan was talking about at 08:18 as he was still referring to the RENDERING time instead of a time increment measured on the basis of an arbitrary engine state. EDIT: I actually don't know if both methods can work in conjunction. If that is the case, then a replacement won't be necessary.
+1. Basically the update has to be sampled at a fixed timestep to guarantee predictable and reproductible results. Not doing this assumes that the whole update is is 'linear' which is not the case for pretty much all the games. A much better strategy is to sample at a fixed timestep - and eventually add protection for a max number of steps (like never more than X update steps per frame) to account for bid delta time jumps (due to freezes etc). What to do in those cases depends on the game: you can either skip updates and 'lose' time or clamp the sampling and go into slomo.
For anyone interested: DirectX UWP template has a fixed timestep timer implementation (named StepTimer) included/generated, quite well commented and documented - worth looking at even as a reference for making your own implmentation.
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.
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.
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.
Most game engines use another method such as fixed time stepping for physics. But this is something that shouldn't be linked to the delta time in your game logic. You don't have to use the same method for both and you shouldn't.
@@AlexanderSartonCozzi it surely is tied to time. The time spent since the beginning of the loop determines how many fixed time updates need to be carried out.
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.
It is and Bethesda isn't the worst case I know. If you for some reason decide to run vanilla GTA San Andreas on a modern PC - DON'T uncheck the frame limiter. If you know the anti-piracy measures from gta4, when on pirated copy of the game cars would never stop driving and get on fire after some time - this is exactly what happens in GTA SA, but because of frame rate. Physics is x times stronger, so cars get pushed into the ground. And so is momentum. You release the W, but your car won't stop rolling. And it also doesn't want to turn. But it seems like traffic is done differently because it's only the cars you drive that get affected by this if I remember correctly.
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.
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?
Don't ever, ever tune the delta time. Just multiply every entity's velocity with another variable that's 1 by default and tune it as you like if you want slowmo.
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?
I just want to clarify that, while allocating objects on the heap, java allocations are way more efficient. That's because it preallocates a whole bunch of memory from the start of the program. So instead of calling malloc on every allocation, it calls it once at start and then again when you run out of memory. And that diminishes the problem where you have your memory everywhere.
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?
I used to do that fixed 60fps vsync thing, i noticed that some drivers even do not implement vsync (correctly). On such platforms you just warp through the world :D
Hi cherno, i want to change the render engine of an actual game (MuOnline)and it has opengl, because the existing one is 12 years old, and resource hungry. I have basic knowledge with c++, i viewed your opengl series first videos, my question is, from where should i start to achieve it?
@@zonkle Can you please explain that to me? Jai has very similar syntax like Rust. Both are non-garbage collected and very fast languages. BTW Rust is available for public and Jai not. So please explain me the biggest differences about these two languages. Why should I wait Jai's release date instead of doing game dev with Rust now? IMO both are very similar or maybe Rust is little bit better than this language because it comes with his safety and very well explained compiler errors. I'm not against to Jai. I just want to know the differences.
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.
This. Fixed timestep with interpolated rendering is absolutely the best way to structure your main loop. Every other method has issues. Too many people are fooled into using delta time in their gameplay code, when it's actually a complete waste of time if you want high precision deterministic gameplay.
Came to the comments section looking for this. I think the reason Yan didn't do it like that is because he hasn't created an entity component system yet. I'm hoping he'll build an alternate timestep system as you suggested in the future once he does set up an ECS, if not replace this method implementation entirely.
I'd also like to add, to avoid misinterpretations, that this suggestion is not the same as what Yan was talking about at 08:18 as he was still referring to the RENDERING time instead of a time increment measured on the basis of an arbitrary engine state.
EDIT: I actually don't know if both methods can work in conjunction. If that is the case, then a replacement won't be necessary.
+1. Basically the update has to be sampled at a fixed timestep to guarantee predictable and reproductible results. Not doing this assumes that the whole update is is 'linear' which is not the case for pretty much all the games. A much better strategy is to sample at a fixed timestep - and eventually add protection for a max number of steps (like never more than X update steps per frame) to account for bid delta time jumps (due to freezes etc). What to do in those cases depends on the game: you can either skip updates and 'lose' time or clamp the sampling and go into slomo.
For anyone interested: DirectX UWP template has a fixed timestep timer implementation (named StepTimer) included/generated, quite well commented and documented - worth looking at even as a reference for making your own implmentation.
@venumspyders Have you got any code you can share for this? I've read Fix Your Time Step numerous times but still can't grasp it.
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.
@M. de k. if yoh want exact reproducibility you have to use fixed time step in your updates.
Doesn't engines like UE4 run physics simulations in a fixed timestep with substepping as an option, while other stuff uses Delta Time?
3 videos, one week. God damn your good! Keep it up!
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.
You're just so good at explaining things.
Thanks for the incredible amount of content you put out!
Thank you! I was looking for a mathematical explanation for this. Now it makes sense.
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.
I was thinking the same thing
Most game engines use another method such as fixed time stepping for physics. But this is something that shouldn't be linked to the delta time in your game logic. You don't have to use the same method for both and you shouldn't.
@@AlexanderSartonCozzi it surely is tied to time. The time spent since the beginning of the loop determines how many fixed time updates need to be carried out.
Very informative video! Thank you for the extra uploads this week, much appreciated! :)
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.
It is and Bethesda isn't the worst case I know.
If you for some reason decide to run vanilla GTA San Andreas on a modern PC - DON'T uncheck the frame limiter.
If you know the anti-piracy measures from gta4, when on pirated copy of the game cars would never stop driving and get on fire after some time - this is exactly what happens in GTA SA, but because of frame rate. Physics is x times stronger, so cars get pushed into the ground. And so is momentum. You release the W, but your car won't stop rolling. And it also doesn't want to turn.
But it seems like traffic is done differently because it's only the cars you drive that get affected by this if I remember correctly.
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.
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?
Don't ever, ever tune the delta time. Just multiply every entity's velocity with another variable that's 1 by default and tune it as you like if you want slowmo.
@@nullbeyondo is there any reason apart from "it's morally wrong"?
Great video, keep it up!
thanks!!
Ty ty ty
Would you gain any performance from running the game loop in the GPU instead?
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?
Im having problems with box2d objects moving VERY slowly with vsync on
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?
Amazing color Theme, what is it?
I just want to clarify that, while allocating objects on the heap, java allocations are way more efficient. That's because it preallocates a whole bunch of memory from the start of the program. So instead of calling malloc on every allocation, it calls it once at start and then again when you run out of memory.
And that diminishes the problem where you have your memory everywhere.
so the movement is consistent even if your framerate fluctuates.
what will happen if I overload the operator float and the operator +
and I try to do "Some Class" + "number.f". What function will be called.
What happens will be what you define in the operator overload function. Exemple: void operator+(int num) { my_int_field += num; }
i might actually use this since ive been watching you create it
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?
Videos are really good and informative but just one thing... *SLOW DOWN* thanks for all the work you do!!!
I used to do that fixed 60fps vsync thing, i noticed that some drivers even do not implement vsync (correctly). On such platforms you just warp through the world :D
running on 165 hz, 6 ms per frame
The VSync doesn't work with me :(
Waiting for model loading episode.
Left.
Why not use std::chrono?
I have a question, how to render things on the window which i created by imgui or move things from default window to imgui window
I guess the next step would be to add a global time dilation term
HEYYY
Hi cherno, i want to change the render engine of an actual game (MuOnline)and it has opengl, because the existing one is 12 years old, and resource hungry. I have basic knowledge with c++, i viewed your opengl series first videos, my question is, from where should i start to achieve it?
Guys, what do you think about Rust programming language? Will it replace C++ for future game dev?
Well yes but actually no.
Absolutely not, ever
The only language that can possibly replace C++ for game development without compromise is Jai.
@Artem Katerynych It's still in development. You can follow Jonathan Blow on twitch and youtube if you're interested.
@@zonkle Can you please explain that to me? Jai has very similar syntax like Rust. Both are non-garbage collected and very fast languages. BTW Rust is available for public and Jai not. So please explain me the biggest differences about these two languages. Why should I wait Jai's release date instead of doing game dev with Rust now? IMO both are very similar or maybe Rust is little bit better than this language because it comes with his safety and very well explained compiler errors. I'm not against to Jai. I just want to know the differences.
thank you , your signature phrase is "right" , maybe don't use that word too much.
Yo
12 minutes ago, wow
Can you please start a series for java programming
Look at ThinMatrix's videos on UA-cam.