[1:20]: Consider using a monotonic clock instead of the system time. Time synchronization (e.g., via the Network Time Protocol (NTP)) can make the system clock jump forward or backward at any point, and leap second smearing can change the length of each second to account for leap seconds.
Your sfml and modern c++ videos where what inspired me to start making video games, something that helped me cope with hard times. I am so happy that youtube suggested this video to me today, as informative, nicely demonstrated as always
This was very educational. I do have to wonder, though, about the draw function causing the loop to encounter mistimings. For example, suppose the game logic runs every 10 ms (i.e., t-slice = 10ms) and it takes 5ms for the draw function to execute. If the draw function is called when the accumulator is at 7ms, the game logic will be 2ms late on the following iteration. It almost seems like the answer is to run the game logic in one thread and handle the graphics in another that only reads the game logic’s memory. Unfortunately that isn’t feasible on every CPU, and I’m not sure what other issues such a design would encounter.
Thank you for this! Also thanks a bunch for listing all the reading material, I'm creating a simulator for a uni project and I would be lost without this
5:20 wow. This time rate thing is fascinating!!! 6:10 I like this pseudocode. 8:10 I liked the graphics. There was Exactly the necessary amount of graphics. No more, no less. I would've liked to see the tick rate thing and how that "solves" some of the aforementioned problems. Instead you just move on to the pseudocode and final statements.
I am focusing on the keyboard and mouse being read at 240Hz, regardless of the framerate, and feeding a render thread to decouple it from rendering, without preventing input during long frames. Desktop environments give you a timestamp on each event of the input queue.
I really liked the video, but I still have to learn more about game logic, so it i'd be really cool if i could find more videos like this. btw thank you for the explaining.
could you tell me how to learn more about this rendering interpolation that you said? i am looking but i cant find. im thinking in let my tick rate be more or less 60, but my refreshrate is 165 everything is very jittered
Terrific video. Presentation makes perfect sense. I have one question. Let's say someone has a low fps and therefore you have to call update five times in a single game loop. Wouldn't this make it so that frame-perfect inputs from the player are no longer possible? The way I understand it is if they press a button any any time during that particular loop, that button will register as being pressed for all five of those updates. Is there something I'm missing, and this isn't actually a problem? Or maybe it is a problem, but there's another solution? Thanks.
Thank you, I am glad you liked the video. You are correct in saying that one possibility is having the input being registered as "held down" for the duration of all those five updates. An alternative would be registering it as such only for the first update. Nevertheless, you are right in saying that frame perfect inputs would not be possible with that system. First of all, is that even a problem? How low does the FPS have to be to have 5 updates per frame? It sounds like this is a edge case of a user with a very unpowered PC. If your game is designed around frame-perfect inputs and you want to support users with extremely low FPSs, then you can have a limit of updates per frame and slow down the game simulation when the limit is reached. That also has its own disadvantages.
A frame is an instance in a second. If you tie movement to the number of frames, the movements vector will be multiplied by the number of frames. If you tie movement to the time between each frame, however, you can guarantee similar speeds across frame rats
Hello, great video! However your first source seems odd to me when it mentions interpolating states using the leftover time in the accumulator. Say the accumulator holds 2.3 time units (which means your simulation is behind by that amount), and dt is 1.0, then the accumulator will be left with 0.3 units after 2 updates. Then there is an interpolation between currentState (state at the second update) with previousState (state at the first update) using a factor of alpha = 0.3, but the currentState is actually 0.3 units in the past (loop condition is accumulator >= dt ) not in the future so doing this interpolation makes no sense to me. Any info?
This discussion on Reddit should help you understand why the interpolation can be useful: old.reddit.com/r/gamedev/comments/10bs23m/gaffer_on_games_fix_your_timestep_question/
Thanks for this video. I think it's great and the animations look nice, but to be honest if it takes you a long time to do these, why not just do them in your previous format? Where you have various files with code and you just show one after the other? I really enjoyed those videos. The code was simple and easy to follow and so were the transitions between code files. Not taking anything from this video, it's really well done and everything flows nice but if you want to produce content I believe just using your previous format of c++ files would be more than enough (there would be no drop in quality in my opinion).
Thank you for the feedback. I am glad you enjoyed the video. I think you do have a point -- the effort required to make a video like this might not be justified, if I can convey the same information with a simpler format. Nevertheless, I think it was an interesting experience, and a fully animated video like this one can be much better than a "traditional" one for visual learners. We'll see... :)
My game still with a very little speed changes when tick rate change. I mutipliyed inside of update movement += speed*Time step; and then in drawn i added movement to X of my square. (that is a INT) and now the movement is almost the same but isnt the same, higher the tick rate higher he accumulate speed and win the race between the two squares. i dont know if the difference is from long, double and int conversors, or if is related to my drawn and update been separeted one from other. The thing is, when my object get out of right side of screen i make it back to 0. And i think that because of the accuracy and because of the more constants updates when 165 ticks it got teleported before to 0 then the other one with 30 ticks, and then it starts to accumulate speed before than the 30 one, and most the time that passes more the difference become bigger.
@vittorioromeo1 im confused. what exactly am i suppose to do with the step? is it to be multiplied with variables such as speed or does it have the same value as t_slice?
The 'step' is a value of your choosing that you can multiply your game calculations by. Think of it as the 'deltaTime' of a basic update/draw loop, but it's chosen by you to achieve the desired game speed and numeric stability.
When I apply that deltaTime, the problem is now the exact opposite, when I render many objects and my FPS is low, the objects seems to be very fast, while theyre quite slow, when having high FPS (fewer objects rendered). What might be the issue? Is that the effect of indeterminism you mentioned?
Just for clarification this is all under the assumption, that update() is faster than draw()? Your points should still all be correct i think, and i don't think, that it will cause any problems besides the games fps beeing slow or slowing down until it's not playable anymore. And this should be easier to fix with (especially with a minimum) unknown hardware than draw()?
'tSlice' is a value of your choosing that represents the minimum amount of time that needs to pass in order to trigger an update. A smaller value of 'tSlice' alongside a smaller 'step' value results in more frequent and more precise updates (but more expensive).
The 'step' parameter of the 'update' function is the same as 'delta time' -- it works exactly in the same way. The only difference is that 'step' is always a fixed value decided by the developer, it doesn't change with the framerate of the game. You can imagine 'update' being a function that takes a floating point number (call it 'dt', 'deltatime', 'step', etc...) and then uses that number to scale the speed of transformations/logic in the game. E.g. void update(float step) { player.position = player.position + player.velocity * step; }
is the ammount of time that you want to pass between updates. for example if your timer (or method to measure time) is in miliseconds (ms) and you want to update 60 times per second so your t_slice will be 1000 miliseconds (1sec) divided by 60, and it will be 0016,6666...7 this is slice, the amount of time that you slice to fit in your update frequency
this is wrong, both update and draw should be concurrent, in their own double buffering, not just the update->draw cycle, your design leads to single threaded mess, unreal
This is a great format. I'd love to see more videos like this one
[1:20]: Consider using a monotonic clock instead of the system time. Time synchronization (e.g., via the Network Time Protocol (NTP)) can make the system clock jump forward or backward at any point, and leap second smearing can change the length of each second to account for leap seconds.
no, please stop posting and giving incorrect information
Your sfml and modern c++ videos where what inspired me to start making video games, something that helped me cope with hard times. I am so happy that youtube suggested this video to me today, as informative, nicely demonstrated as always
It makes me really happy to hear that I had a positive impact on your life! Glad you enjoyed the video, and keep it up :)
This was very educational.
I do have to wonder, though, about the draw function causing the loop to encounter mistimings. For example, suppose the game logic runs every 10 ms (i.e., t-slice = 10ms) and it takes 5ms for the draw function to execute. If the draw function is called when the accumulator is at 7ms, the game logic will be 2ms late on the following iteration.
It almost seems like the answer is to run the game logic in one thread and handle the graphics in another that only reads the game logic’s memory. Unfortunately that isn’t feasible on every CPU, and I’m not sure what other issues such a design would encounter.
Thank you for this! Also thanks a bunch for listing all the reading material, I'm creating a simulator for a uni project and I would be lost without this
Hope you’ll continue, I follow you since your talk on ECS and you do really great !
5:20 wow. This time rate thing is fascinating!!!
6:10 I like this pseudocode.
8:10 I liked the graphics. There was Exactly the necessary amount of graphics. No more, no less.
I would've liked to see the tick rate thing and how that "solves" some of the aforementioned problems. Instead you just move on to the pseudocode and final statements.
Great job! I definitely want to watch more videos like this
this is exactly what I needed. thank you so much!
Loved this deep explanation about loops! Keep going on it, man ^^
Great explanation as usual. Thanks. Now, some modern C++ implementation if you please
I am focusing on the keyboard and mouse being read at 240Hz, regardless of the framerate, and feeding a render thread to decouple it from rendering, without preventing input during long frames. Desktop environments give you a timestamp on each event of the input queue.
I really liked the video, but I still have to learn more about game logic, so it i'd be really cool if i could find more videos like this. btw thank you for the explaining.
I knew I recognized this clock. That gaffer article is super useful
You have a great presentation style. Nice video
thanks, this is literally what i've searched for
Very nice presentation and useful information.
could you tell me how to learn more about this rendering interpolation that you said? i am looking but i cant find.
im thinking in let my tick rate be more or less 60, but my refreshrate is 165 everything is very jittered
Terrific video. Presentation makes perfect sense.
I have one question. Let's say someone has a low fps and therefore you have to call update five times in a single game loop. Wouldn't this make it so that frame-perfect inputs from the player are no longer possible? The way I understand it is if they press a button any any time during that particular loop, that button will register as being pressed for all five of those updates.
Is there something I'm missing, and this isn't actually a problem? Or maybe it is a problem, but there's another solution? Thanks.
Thank you, I am glad you liked the video.
You are correct in saying that one possibility is having the input being registered as "held down" for the duration of all those five updates. An alternative would be registering it as such only for the first update. Nevertheless, you are right in saying that frame perfect inputs would not be possible with that system.
First of all, is that even a problem? How low does the FPS have to be to have 5 updates per frame? It sounds like this is a edge case of a user with a very unpowered PC.
If your game is designed around frame-perfect inputs and you want to support users with extremely low FPSs, then you can have a limit of updates per frame and slow down the game simulation when the limit is reached. That also has its own disadvantages.
Are step & T-slice not the same value?
i still dont understand but cool
A frame is an instance in a second.
If you tie movement to the number of frames, the movements vector will be multiplied by the number of frames.
If you tie movement to the time between each frame, however, you can guarantee similar speeds across frame rats
I mean bro explained it so clear, but you can't get it if you've never got basics of programming
Excellent ! Thanks
Hello, great video!
However your first source seems odd to me when it mentions interpolating states using the leftover time in the accumulator.
Say the accumulator holds 2.3 time units (which means your simulation is behind by that amount), and dt is 1.0, then the accumulator will be left with 0.3 units after 2 updates. Then there is an interpolation between currentState (state at the second update) with previousState (state at the first update) using a factor of alpha = 0.3, but the currentState is actually 0.3 units in the past (loop condition is accumulator >= dt ) not in the future so doing this interpolation makes no sense to me. Any info?
This discussion on Reddit should help you understand why the interpolation can be useful:
old.reddit.com/r/gamedev/comments/10bs23m/gaffer_on_games_fix_your_timestep_question/
Thank you, good stuff!
Thanks for this video. I think it's great and the animations look nice, but to be honest if it takes you a long time to do these, why not just do them in your previous format?
Where you have various files with code and you just show one after the other? I really enjoyed those videos. The code was simple and easy to follow and so were the transitions between code files.
Not taking anything from this video, it's really well done and everything flows nice but if you want to produce content I believe just using your previous format of c++ files would be more than enough (there would be no drop in quality in my opinion).
Thank you for the feedback. I am glad you enjoyed the video.
I think you do have a point -- the effort required to make a video like this might not be justified, if I can convey the same information with a simpler format.
Nevertheless, I think it was an interesting experience, and a fully animated video like this one can be much better than a "traditional" one for visual learners. We'll see... :)
love this.
My game still with a very little speed changes when tick rate change.
I mutipliyed inside of update movement += speed*Time step;
and then in drawn i added movement to X of my square. (that is a INT)
and now the movement is almost the same but isnt the same, higher the tick rate higher he accumulate speed and win the race between the two squares.
i dont know if the difference is from long, double and int conversors, or if is related to my drawn and update been separeted one from other.
The thing is, when my object get out of right side of screen i make it back to 0. And i think that because of the accuracy and because of the more constants updates when 165 ticks it got teleported before to 0 then the other one with 30 ticks, and then it starts to accumulate speed before than the 30 one, and most the time that passes more the difference become bigger.
@vittorioromeo1 im confused. what exactly am i suppose to do with the step? is it to be multiplied with variables such as speed or does it have the same value as t_slice?
The 'step' is a value of your choosing that you can multiply your game calculations by. Think of it as the 'deltaTime' of a basic update/draw loop, but it's chosen by you to achieve the desired game speed and numeric stability.
When I apply that deltaTime, the problem is now the exact opposite, when I render many objects and my FPS is low, the objects seems to be very fast, while theyre quite slow, when having high FPS (fewer objects rendered). What might be the issue? Is that the effect of indeterminism you mentioned?
Just for clarification this is all under the assumption, that update() is faster than draw()?
Your points should still all be correct i think, and i don't think, that it will cause any problems besides the games fps beeing slow or slowing down until it's not playable anymore.
And this should be easier to fix with (especially with a minimum) unknown hardware than draw()?
What do you do if the update is the performance bottleneck, not the draw?
I would go through the regular profile-optimize loop, and consider adding task-based multithreading if necessary.
Where is tslice is assigned or declared ?
'tSlice' is a value of your choosing that represents the minimum amount of time that needs to pass in order to trigger an update.
A smaller value of 'tSlice' alongside a smaller 'step' value results in more frequent and more precise updates (but more expensive).
@@vittorioromeo1 Thank you
nice! :3
Curious, do you have your "GetInput()" inside the while or before?
In Open Hexagon, I call `getInput` outside of the update while loop, once per frame.
in the last example can someone please explain to me what the step variable is and how the update function si designed? thank you
The 'step' parameter of the 'update' function is the same as 'delta time' -- it works exactly in the same way. The only difference is that 'step' is always a fixed value decided by the developer, it doesn't change with the framerate of the game.
You can imagine 'update' being a function that takes a floating point number (call it 'dt', 'deltatime', 'step', etc...) and then uses that number to scale the speed of transformations/logic in the game. E.g.
void update(float step) { player.position = player.position + player.velocity * step; }
what is t_slice?
is the ammount of time that you want to pass between updates.
for example if your timer (or method to measure time) is in miliseconds (ms) and you want to update 60 times per second so your t_slice will be 1000 miliseconds (1sec) divided by 60, and it will be 0016,6666...7
this is slice, the amount of time that you slice to fit in your update frequency
i feel like I learned a lot but nothing at the same time lol
c'è bisogno di più italiani nella comunity inglese
it's impossible to get a game loop right on windows.
do you mind elaborating why 🤔
@@k00lmoh Myths and Misconceptions of Frame Pacing / Alen Ladavac, Croteam / Reboot Develop Blue 2019
this is wrong, both update and draw should be concurrent, in their own double buffering, not just the update->draw cycle, your design leads to single threaded mess, unreal
Not every game needs concurrent double-buffered update/draw separation. What you're suggesting adds a lot of often unnecessary complexity.
your "one universal truth" is not a truth, and you are very single threaded, mind you@@vittorioromeo1
you gonna be waiting for the graphics or updates to finish, so wasting cycles@@vittorioromeo1
background updates to various things@@vittorioromeo1
almost every engine does this, so what you suggest is regressing to old past that does not need to be there@@vittorioromeo1