Timing game loop

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

Recommended Posts

Is there a standard value for the amount of time I should wait between each update of the main thread? I'm using SFML on c++, right now I just have a basic loop:

while(game.isRunning()){

game.HandleEvent();

game.Update();

game.Paint();

//time sleep method

}

I'm making a 2d game, so how long should the loop wait before starting over?

Share on other sites

You usually don't sleep at all in a game. You could yield (SwitchToThread on windows) if you really want, but it's not like we're still using win9x kernels or something.

Also keep in mind you'll already be sleeping until vsync if you're using vsync in your game.

Share on other sites

If you're not using a fixed time step or waiting for vsync, you may want to keep track of the time between frames. Which in your case it's pretty simple, a frame is each run of your game loop.

You should start a clock right before your game loop starts. At the beginning of each loop save the clock time and restart the clock. This would typically be called the game time as it'll be the time between the previous from to the beginning of the next frame. You would then pass this game time around to the various parts of your game to make sure everything is executed at the correct speed. I.E  movement of objects, physics, etc.

Share on other sites

You usually don't sleep at all in a game. You could yield (SwitchToThread on windows) if you really want, but it's not like we're still using win9x kernels or something.

Also keep in mind you'll already be sleeping until vsync if you're using vsync in your game.

I may have asked this the wrong way.  What I meant was what kind of time step should I use so that it doesn't look like the sprites are flying across the screen at mach 3?

Share on other sites

You usually don't sleep at all in a game. You could yield (SwitchToThread on windows) if you really want, but it's not like we're still using win9x kernels or something.

Also keep in mind you'll already be sleeping until vsync if you're using vsync in your game.

I may have asked this the wrong way.  What I meant was what kind of time step should I use so that it doesn't look like the sprites are flying across the screen at mach 3?

Try doing what I suggested above, and when you're manipulating the speed of your sprites, make sure to multiply the speed by the game time.

I.E

objectPosition.x = objectPosition.x + (speed * gameTime).

This would make sure the speed value for your object is only as fast as the time step. The longer it takes for the next frame (or loop) to begin, the greater that speed value will end up being, and vice versa.

Say it takes .161 seconds to go from frame 1 to frame 2, and you have a speed of 50.  50 * .161. Doing the math would give you a 'speed for this frame' of 8.05, and thus would only move the sprite by that much, instead of the full 50.

Edited by SolarChronus

Share on other sites

objectPosition.x = objectPosition.x + (speed * gameTime).

Just change gameTime to frameTime. The amount of time since the last update of your game (time since the loop…looped).

If you have any form of physics, a fixed time step will also be necessary.
Fixed-Time-Step Implementation

L. Spiro

Share on other sites

You usually don't sleep at all in a game. You could yield (SwitchToThread on windows) if you really want, but it's not like we're still using win9x kernels or something.

Also keep in mind you'll already be sleeping until vsync if you're using vsync in your game.

I may have asked this the wrong way.  What I meant was what kind of time step should I use so that it doesn't look like the sprites are flying across the screen at mach 3?

You want to update sprites at 30-75 Hz. 75Hz is at the high end of what a LCD will display. A frame rate higher than the monitor refresh rate cannot be seen. 60Hz is also a common limit for monitors. You may be able to poll the OS to find out the current display refresh rate. 30 Hz is the low end of what will look like smooth motion. You can run slower, but then tics start being visible.

Share on other sites
If anything, only throttle the drawing of objects. If you throttle input/physics it will make your game seem laggy. So basically just keep a timer and do something like
input();
update_states();
physics();
if(cur_time > max_frame_time) draw(), cur_time = 0;
cur_time += frame_time;


Share on other sites

If you have any form of physics, a fixed time step will also be necessary.
Fixed-Time-Step Implementation

What a great explanation.

Share on other sites

To play nice you can put in a Sleep(0).

This will yield your process to anything else that needs processing time after you finished your game loop.

If you do not do this then your process will starve anything waiting and eventually Windows will slice you out at some random place in the game-loop.

The nice part of Sleep(0) is if nothing is waiting then it returns to your app right away (unlike Sleep(1) which will probably take 10ms).

• Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 16
• 13
• 9
• 11
• 15