Sign in to follow this  
Crazyfool

Game Loops

Recommended Posts

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 this post


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


Link to post
Share on other sites
Quote:
Original post by Koobazaur
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.


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 this post


Link to post
Share on other sites
Quote:
Original post by Rand
Quote:
Original post by Koobazaur
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.


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.

It's definitely the best method I've read about so far; now I just wish I had that link.

Share this post


Link to post
Share on other sites
Quote:
Original post by templewulf
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:

*** 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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this