   Framerate control or frame independent gameplay?
  I am working on a game, called HardPoint 4.There is a thread in Help Wanted about it, but by my interpretation of that forum's guidelines I'm not supposed to post this there. If this is wrong, would an admin please move it or something... Thanks.My code is really long, should I try to change all the move(...) methods (methods that update objects for the new frame) to take a framerate parameter, and modify their contents so that all movement and time functions are like:newchange = oldchange * framerate / idealrate?I will start coding a copy of my code like this to test, but feedback would be nice.   
  Probably the 'best' way todo is to decouple framerate from world update rate. So you update the world state every x milliseconds but render as fast as possible.   ;  This thread caught my eye because its something I've been working on recently.  My old design had things set up to achieve the fastest possible framerate, but in a much-too-linear fashion. do  Animate  RenderrepeatOver last weekend, I made a change which basically allows the loop to only cycle once every X milliseconds, as compared to the above loop which simply runs as fast as possible.do  EnforceTimeStep  Animate  RenderrepeatI don't like it.  It just seems to be a throttle, and it only looks good when its wide open.Based upon phantom's suggestion above, I'm thinking about doing this:do  if TimeToAnimate then Animate  RenderrepeatBut if I go this way, I'm thinking I'll have to venture into the world of Position Interpolation prior to the Render step.  In fact, maybe the Animate steps goes away entirely, and is replaced by 2 steps like this:do  if TimeToUpdateWorld then UpdateWorld  InterpolatePositions  RenderrepeatI wonder if I'm on the right track here...  This last one seems to be a good fit for multi-user client/server stuff.  I wonder if this might be overkill for single-user games.   ;  Sorry if i misunderstood your goal, but isn't it better to base things on time rather then on framerate? Simply instead of making:position += step;every frame i do:position += step_per_second * time;Where time is a float and where 1.0 equals to 1 second. Once again i'm not sure if i got your quiestion right. Are you trying to lock framerate on certain value or something?   ;Quote:Original post by phantomProbably the 'best' way todo is to decouple framerate from world update rate. So you update the world state every x milliseconds but render as fast as possible.Why draw again if nothing has changed? Isn't waste? Am I missing something? With this approach I could render 3 (random number ;) ) times between two updates and all those frames would look same, or not?   ;  The standard way of dealing with this is to calculate the elapsed time since the last frame as a floating point number expressed in seconds and have all animations update by that time interval. Interpolate between keyframes where possible.To calculate the elapsed time use QueryPerformanceCounter() and QueryPerformanceFrequency() as the standard windows timer isn't very accurate. Note that due to the low accuracy of floating point maths you should subtract the two QueryPerformanceCounter() results before converting to a float.I would also recommend limiting the max time interval to around 0.1 seconds to avoid problems with high time deltas. Also if it's running under 10 fps then something unusual has probably happened, for example windows hitting the swap file or you just loaded the next level.You probably want code that looks something like this:LARGE_INTEGER LastTime;float InverseTimerFrequency;void Init(void){  // Set up the timer - this only needs doing once  LARGE_INTEGER Frequency;  QueryPerformanceFrequency(&Frequency);  InverseTimerFrequency = 1.0f / (float)Frequency.QuadPart;  QueryPerformanceCounter(&LastTime);}void Update(void){  LARGE_INTEGER time;  QueryPerformanceCounter(&time);  float fElapsedTime = (float)(time.QuadPart - LastTime.QuadPart) * InverseTimerFrequency;  if (fElapsedTime > 0.1f) fElapsedTime = 0.1f;  LastTime = time;  UpdateTheGame(fElapsedTime);  Render();};Quote:Original post by lopenkaWhy draw again if nothing has changed? Isn't waste? Am I missing something? With this approach I could render 3 (random number ;) ) times between two updates and all those frames would look same, or not?That's why you still interpolate between two states. Of course you could argue that in a game with nothing but simple linear changes that isn't really making a difference, but even then you only interpolate for display and without doing any real physics or AI. Additional benefit is that you can have different timings for different kinds of updates. If you figure "updating the AI 5 times per second is enough" you can do so without making the game unplayable at 5fps (or wasting time on pointless updates).Just multiplying everything with delta_time is nice and easy and perfectly fine for many uses, but when it comes to being reproducable or syncing multiple clients it's a nightmare. Just ask the developers of X-Wing vs. Tie-Fighter, they had a nice article about their woes somewhere ,-)   ;  I just searched the forum on this question because I want to start a game project. I already programmed games but those always used the "do a game logic update every frame" approach which isn't optimal AFAIK. In this thread:http://www.gamedev.net/community/forums/topic.asp?topic_id=326655the idea by Promit seems to be very good to me. Perhaps it would be even better if I would do one game logic step in advance , so I always have two steps available and I can interpolate between them, so if I want to update the game logic every 10ms and it takes 15ms for one frame I do one game logic step and interpolate the "half" step. Then if the next step takes only 5ms I don't have to interpolate but I do a new logic step anyway in case that I have to interpolate again the next frame.What do you think, IMHO this sounds good but I'm not 100% sure.   