//End of game loop:
//Wait until 25 ms has passed.
while ((GetTickCount() - starting_point) < 25)
{
DoSomething();
}
Game Loops
Author
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:
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.
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:
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).
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).
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.
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.
Quote:Original post by RandQuote: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.
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
