# Game Loops

## Recommended Posts

Crazyfool    307
Hi, I made my gamae loop and thought nothing more of it for a bit while I did the other functions to make it work. I capped it at like 33 frames per sec (it was from a tutorial were I got the base of my loop) Anyway, I have read somewhere about game loops and problem with capping it too low, good computers will have wasted cycles, and too high, low computers will be laggy. Well, it had some solutions that I think are too advanced for me (it's been a while), but I was thinking of something like this:
//End of game loop:
//Wait until 25 ms has passed.
while ((GetTickCount() - starting_point) < 25)
{
DoSomething();
}

Where DoSomething() will do just exactly that.. something. Perhaps it is save the game, load a file, something. Is this a good idea or could it lead to unpredictable frame rates ?

##### Share on other sites
tstrimp    1798
What happens if DoSomething takes a while? It could delay the start of the next game loop by the amount of time it takes to run.

##### Share on other sites
templewulf    526
Unfortunately, I lost the link, but there was a method which could cope with varying frame rates and still keep the physics fairly sane. I don't know if that has any meaning for you, but here it is:

int main(int argc, char** argv){	Game game;	double accumulator = 0;	double timeStep = 1.0f / 60.0f;	//60 physics updates per second	double thisTime = 0;	double lastTime = GetTime();	while(game.IsActive())	{		thisTime = GetTime();		accumulator += thisTime - lastTime;		//the outer loop builds up the accumulator while this inner loop "consumes" it until it catches up		//this is necessary so that you don't miss collisions when your time steps are especially large		while(accumulator > timeStep)		{			Update(timeStep);			accumulator -= timeStep;		}		Render();		sleep(0);  //or yield() or whatever your equivalent is	}	return 0;}

Of course, you'll have to add certain precautions, like ensuring that the accumulator doesn't get higher than a couple of seconds (I cap mine at 1 second).

##### Share on other sites
Koobazaur    1264
What I would suggest, honestly, ditch the frame cap. Render it as often as possible (each loop) and base your game mechanics on the time passed, not the frame rate.

##### Share on other sites
Rand    193
Quote:
 Original post by KoobazaurWhat I would suggest, honestly, ditch the frame cap. Render it as often as possible (each loop) and base your game mechanics on the time passed, not the frame rate.

I would partially 2nd this. Pass the time passed into all the update code, but then cap the frame rate at 30 or 60 or however fast your code can go. What this does is gives more accurate calculations to each part of the game. Instead of updating in 'big' steps of 25ms, the update can be exactly 23ms or 27ms. This should lead to less jitterness.

##### Share on other sites
templewulf    526
Quote:
Original post by Rand
Quote:
 Original post by KoobazaurWhat I would suggest, honestly, ditch the frame cap. Render it as often as possible (each loop) and base your game mechanics on the time passed, not the frame rate.

I would partially 2nd this. Pass the time passed into all the update code, but then cap the frame rate at 30 or 60 or however fast your code can go. What this does is gives more accurate calculations to each part of the game. Instead of updating in 'big' steps of 25ms, the update can be exactly 23ms or 27ms. This should lead to less jitterness.

This is exactly what the accumulator does in the method I posted earlier. It sounds like the OP might be a bit early for this kind of thing, but if your update loop is volatile in the times it returns, you could miss physics updates at the peak of a jump entirely, and in pixel-perfect games like Mario, you wouldn't actually touch the block at the top of your jump. Having updates "eat" equal-sized chunks of the accumulator at every step keeps your physics predictable.

##### Share on other sites
Degra    212
Quote:
 Original post by templewulfUnfortunately, I lost the link, but there was a method which could cope with varying frame rates and still keep the physics fairly sane. I don't know if that has any meaning for you, but here it is:*** Source Snippet Removed ***Of course, you'll have to add certain precautions, like ensuring that the accumulator doesn't get higher than a couple of seconds (I cap mine at 1 second).

This looks like it.. clicky

Degra