Why pause/sleep in game loop
Author
I am wondering why we need to pause/sleep in game loop?
I previously had a timer check to make sure the loop run only after 33 ms.
Recently, I am dealing with using the Sleep(30) function.
I am confuse because when I don't have cap, It run much smoother.
Could anyone shed some light?
cheers!
I've never slept in any of my real time game.. just render as fast as you can and update everything that move with a deltaTime (time since last frame) parameter.
You must know rendering and game logic is two separate things which might not be at the same frequency, like in Doom3 which blocked the game tick at 60fps, but I don't know why.
You must know rendering and game logic is two separate things which might not be at the same frequency, like in Doom3 which blocked the game tick at 60fps, but I don't know why.
Quote:Original post by Dunge
You must know rendering and game logic is two separate things which might not be at the same frequency, like in Doom3 which blocked the game tick at 60fps, but I don't know why.
I think Carmack decided to do that for physics...
- Pause is of course a nice feature for many hard-action arcade game.
- program is windowed and is supposed to be used in same time with other programs. Sleep gives the other programs some CPU time. Of course, if the program doesn't need a constant updating, then it may rely on WM_PAINT messages or such that it doesn't take any more CPU time as is necessary.
- Sleep isn't very accurate. Also, having a constant sleep time isn't maybe the best thing to do. Very likely it will result jerky animation etc. Consider that your game logic update takes variable time every time it is done, and then you wait for a constant time. This leads to the situation that your updates happen in non-constant time step.
- You should separate your logic updates from the drawn frames. You can update your game logic like 25-30hz and draw as many interpolated frames as you can/want.
Cheers
One reason to use sleep is to simulate heavy load on the system.. i.e insert a sleep inside your pathfinding loop and develop it at that speed. Once you get it running nicely with sleep enabled - disable it for a speedboost. :)
Another use would be to prevent a thread from using to much processing power, but that could also (and should) be done with thread priority.
Cheers!
Another use would be to prevent a thread from using to much processing power, but that could also (and should) be done with thread priority.
Cheers!
The reason why a call to Sleep is typically issued (in CPU-resource munching applications) is to hand over some time slices to other programs on the OS, as to avoid the 100% CPU usage scenario.
However, the update thread should not always be running at full speed, as to avoid poor stability with physics that use time stepping. Games typically lock the update thread at a fixed rate, say 60 Hz (Doom III). The render loop could be synced with the update loop, or both could be synced with the refresh rate of the monitor (which, as it turns out, is also typically 60 Hz for large flat-screen displays).
However, the update thread should not always be running at full speed, as to avoid poor stability with physics that use time stepping. Games typically lock the update thread at a fixed rate, say 60 Hz (Doom III). The render loop could be synced with the update loop, or both could be synced with the refresh rate of the monitor (which, as it turns out, is also typically 60 Hz for large flat-screen displays).
The best approach I have seen is a hybrid of the fixed timestep and deltaTime types. I thought deltaTime would be best, but because of differences in timesteps, a lot of physics equations get thrown out of whack. Interpolation becomes much harder.
The hybrid approach has a time accumulator, and every time the timer::Update() function runs, it adds deltaTime to the accumulator.
Separately, the physics are updated in equally-sized time chunks. So, the scene::Update() routine checks the accumulator to see if it has enough time to run a frame (say, 60Hz, so at least .0166667 seconds). Then, it reduces the accumulator by that much time for each frame update. It repeats this until the accumulator does not have enough time to run another frame.
This produces even results for physics equations, and it allows for small variances in performance. You may want to cap the timer at some small number (I wouldn't go any higher than 2 seconds), because you don't want to accidentally let the timer run for a while, then the scene takes hours to complete all its updates.
Getting back to the sleep() function, I call it once the scene updating loop exhausts all the free time from the accumulator. You can just give up control with sleep(0), that way you don't have to specify a particular time to sleep for. Your application just gets control back when the OS decides other programs have had enough.
The hybrid approach has a time accumulator, and every time the timer::Update() function runs, it adds deltaTime to the accumulator.
Separately, the physics are updated in equally-sized time chunks. So, the scene::Update() routine checks the accumulator to see if it has enough time to run a frame (say, 60Hz, so at least .0166667 seconds). Then, it reduces the accumulator by that much time for each frame update. It repeats this until the accumulator does not have enough time to run another frame.
This produces even results for physics equations, and it allows for small variances in performance. You may want to cap the timer at some small number (I wouldn't go any higher than 2 seconds), because you don't want to accidentally let the timer run for a while, then the scene takes hours to complete all its updates.
Getting back to the sleep() function, I call it once the scene updating loop exhausts all the free time from the accumulator. You can just give up control with sleep(0), that way you don't have to specify a particular time to sleep for. Your application just gets control back when the OS decides other programs have had enough.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
