   fps, sync and timers [solved]
  How do I make sure my game runs at the same speed on all computers? I don't want to lock the fps since I want as high fps as possible.I was thinking about saving the time it takes to render a frame and multiply it with the speed when moving stuff the next frame. But then I get another problem, timers. My game is using OpenGL/SDL (for Linux) but SDL_GetTicks() is not acurate enough.Any ideas?[Edited by - eXt_ on December 13, 2005 10:00:46 AM]
  You could do what you said; find out the time since your last game Update function( or whatever you've called it ) and pass something like deltaTime:This would look something like..while( 1 ) {    renderer.Draw();    newTime = timer.GetTime();    game.Update( newTime - lastTime ); // dTime    lastTime = newTime;}And then base your movement on the dTime like you said. This should make the game run at the same speed everywhere, but you'll probably have to take care of multiplying movement * dTime 'a lot' in your game.Update() function.I prefer to have something like this:while( 1 ) {    renderer.Draw();    newTime = timer.GetTime();    if( ( newTime - lastTime ) &gt; 20 ) {    // if 20 ms have passed, run Game.Update()   game.Update();   lastTime = newTime;    }}This would simplify Game.Update() a bit, since you don't have to use dTime to calculate movement / anything inside the Game.Update() function. If the computer can't process renderer.Draw() and game.Update() within 20 ms however, the game will run slower. For timers, looks up QueryPerformanceCounter(/Timer?).I'd write more, but my bath is full... more text soonish -_-[Edited by - Salteh on December 13, 2005 9:01:19 AM];  Rather than setting lasttime=newtime you could set lasttime+=20. You then process frames until lasttime>newtime-20. Also rather than update then draw you have a series of updates and then a draw at the end. That will keep you from running slower if you can't keep up. The only thing to watch is if the update takes more than 20ms. If so then you can never catch up. Most of the work is on the draw so that shouldn't really be a problem in a properly tuned application.   ;Quote:Original post by SaltehI prefer to have something like this:while( 1 ) {    renderer.Draw();    newTime = timer.GetTime();    if( ( newTime - lastTime ) > 20 ) {    // if 20 ms have passed, run Game.Update()   game.Update();   lastTime = newTime;    }}This would simplify Game.Update() a bit, since you don't have to use dTime to calculate movement / anything inside the Game.Update() function. If the computer can't process renderer.Draw() and game.Update() within 20 ms however, the game will run slower. For timers, looks up QueryPerformanceCounter(/Timer?).I'd write more, but my bath is full... more text soonish -_-But wouldn't that lower my fps since it draws fewer frames? I found gettimeofday() which should be enough acurate, but I'm thinking of making an function to make porting easy.   ;  That would run the renderer.Draw() function whenever it can, but only run the game.Update() function every 20 ms. So it'd basically render the same frame over and over again until 20 ms have passed - then it'll run Update() and do whatever your game.Update() does... Move entities, explode, whatever.Quote:Also rather than update then draw you have a series of updates and then a draw at the end. That will keep you from running slower if you can't keep up.hmm? I'm still thinking about this.. do you have an example? :);  With your example just use while rather than if and lasttime+=20 rather than lasttime=newtime.   ;  But if we update as many times as possible like that the speed would vary on different computers. The solution would be to multiply with the time it takes to update but that would also slow things down. Am I right?   ;  @eXt_Nope, there is no big performance hit with multiplying i.e. velocity with elapsed time   ;Quote:Original post by eXt_But if we update as many times as possible like that the speed would vary on different computers. The solution would be to multiply with the time it takes to update but that would also slow things down. Am I right?The part of my reply which you quoted would call renderer.Draw()(which should only draw stuff, not modify game data) as many times as possible, but only call game.Update() every 20 ms.This is assuming you have seperated rendering / game logic :).;Quote:Also rather than update then draw you have a series of updates and then a draw at the end. That will keep you from running slower if you can't keep up.I was thinking about that post...Well, anyway, I got things workin smooth by the method you showed Salteh =) Thanks!   