Jump to content
  • Advertisement
Sign in to follow this  
lXciD

Why pause/sleep in game loop

This topic is 4219 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites


- 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




Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!