   Game timing: maintaining a constant number of updates-per-second
  My game project currently uses frame-rate independant timing, such that it will attempt to update game logic at a constant 60 times per-second irregardless of what the framerate is. This works by gauging how long the previous frame took to render, and incrementing an updateSum by the ratio of how long it took and how long a frame should ideally take to render. Thus, if a frame takes twice as long to draw than what it should, the game will update twice and draw once to maintain the constant update-rate. Similarly, if a game draws twice as fast as it should, the game will run update logic only once every other frame.Given this, there are no issues with any framerate. However, this method ceases to work when game logic updates start to become expensive. The framerate will remain high, but the update-rate will drop steadily.Even if you don't completely follow my explanation above on how I'm currently doing things, the underlying question is the same: what method(s) is/are ideal for maintaining a constant number of updates per-second, independant of how long frames take to draw, and how long logic updates take to execute.Any advice on the matter is greatly appreciated.   
  Personally, any visual logic that I need to measure (be it frames of animation or distance over time) I simply multiply by the change in time from one frame render to the next.In 2D for example, if I had a ball that bounced around the screen, I would have it travel at 80 pixels (or another relative distance measurement) per second.x=x+80*((time at last frame rendering)-(current time))I just make sure that nothing in my code needs to actually be updated within any set length of time, so that even if the program halted for 10 minutes... it could catch itself back up based on knowing exactly how much time had passed. If your engine is set up properly, your positioning for music, animations, movement, and even collision detection will take time into account. Collision Detection becomes a little tricky there because instead of checking every frame if something collides, you check if a collision simply could have happened between the last update and the next.   ;Quote:Original post by MythicsPersonally, any visual logic that I need to measure (be it frames of animation or distance over time) I simply multiply by the change in time from one frame render to the next.In 2D for example, if I had a ball that bounced around the screen, I would have it travel at 80 pixels (or another relative distance measurement) per second.x=x+80*((time at last frame rendering)-(current time))While this works fine for values that can be linearly scaled, it falls apart when a dependant variable that changes over time comes into play.For example, say you have a friction constant that you apply to a character's friction per-update:velocity -= velocity * friction * magicDeltaAsAbove;You will find that you get rather different results in terms of "how soon the player stops due to friction" based on how large the delta multiplier is. This is why I need an approach that allows the game to perform "full" updates 60 times per second rather than linearly scaling my values. Thanks for the reply, though.   ;  Why 60 physics updates per second? You may be able to get away with a lower value and still have it acceptable (though you'd have to test and tweak it).I run my asteroids game at ~30 updates per second, it could probably be a bit lower if I used extrapolation during rendering.   ;  It doesn't really matter what the number is, he's looking on how to do it.Personally, I'd just go and use Box2D off the bat, but if you insist on doing it yourself, you may be interested in Chris Hecker's physics articles, or Gaffer's article on timesteps.   ;Quote:Original post by HopeDaggerFor example, say you have a friction constant that you apply to a character's friction per-update:velocity -= velocity * friction * magicDeltaAsAbove;You will find that you get rather different results in terms of "how soon the player stops due to friction" based on how large the delta multiplier is. This is why I need an approach that allows the game to perform "full" updates 60 times per second rather than linearly scaling my values. Thanks for the reply, though.I may still be missing something, but using what I was trying to describe you would be able to calculate when the player would stop ahead of time instead of checking during each update as to whether or not they should stop yet. The only way things would change is if input from the user or some other calculated data (another object collides with the player which results in a change of velocity for example) would affect the result. When that change is made (input received), the calculation would be updated on the spot.In the end, you would know if it would take 10 seconds for the player to stop or w/e and you would also know the position of the player when they would come to that complete stop. If you made those adjustments based on the time passed, a simple function could be called to get the player's current position/velocity/etc based on the time you input into the function instead of doing something every single update.   ;  All you need to do is keep track of elapsed time, and run the correct number of updates to catch up. The only way this will cause problems is if game logic updates take longer than 1/60th of a second.float fUpdateTime = 0.0f;void Update(float fElapsedTime){  fUpdateTime += fElapsedTime;  while (fUpdateTime > 1.0f / 60.0f)  {    UpdateGameLogic();    fUpdateTime -= 1.0f / 60.0f;  }}My other post here explains how to calculate the update time.If an individual update takes longer than 1/60th of a second then you're in trouble - that probably means that the CPU isn't quick enough to run at that update rate. The only solution is to reduce the update rate, or optimize the update code.My recommendation would be to limit it to a maximum of 6 logic updates per frame. That way when CPU bound the game will just slow down rather than lock up. My timer code from the other thread will do this already by limiting the maximum time step.   ;Quote:Original post by Adam_42All you need to do is keep track of elapsed time, and run the correct number of updates to catch up. The only way this will cause problems is if game logic updates take longer than 1/60th of a second.*** Source Snippet Removed ***My other post here explains how to calculate the update time.If an individual update takes longer than 1/60th of a second then you're in trouble - that probably means that the CPU isn't quick enough to run at that update rate. The only solution is to reduce the update rate, or optimize the update code.My recommendation would be to limit it to a maximum of 6 logic updates per frame. That way when CPU bound the game will just slow down rather than lock up. My timer code from the other thread will do this already by limiting the maximum time step.I must be very tired... 6 updates a frame?  You mean you do 6 frames per update right?  I am assuming here that updates are typical "updates", networking, physics, AI and you just had it reversed...;  I do mean 6 updates per frame.You want 60 logic updates per second. If you're running on a really slow computer that can only manage to do a logic update in say 1/30 second then you have a problem - there's no way you can do your 60 updates per second. 30 is the absolute limit, and you won't manage that unless rendering is instant.If you try to do 60 per second you'll be doing more and more updates each frame, and the game will get slower and slower. It'll appear to lock up within seconds of starting. The first frame will do one update then render, next frames are 2, 4, 8, 16, 32, etc updates.To fix that problem you limit the maximum number of logic updates to a frame to some small value. The game will now run, but at a reduced update rate and low frame rate.The other (more likely) way to hit that limit is when one frame takes a really long time to render or update for some reason out of your control. If that happens the limit will stop it running loads of logic updates on the next frame to try and catch up. In addition if it ran lots of updates on that frame, it'll take longer and run lots on the next frame too. It'll look like the game is in fast forward mode for a little while after that pause.   ;Quote:Original post by Adam_42You want 60 logic updates per second.That right there is the problem. No matter what kind of calculation we're talking about, there should never be a requirement to update anything any number of times per second or even minute.If the math was done properly, you could 'update' once every 10 minutes and accomplish the same goals.The only limitations should be when the calculations change, and they shouldn't unless there's a random event firing.. input from a user.. or something coming across the network that instigates a change.For example, if you know the movement direction of an object, it's velocity, acceleration, friction values, etc.. you should already know when that object will stop or when it will collide with another object. You should already have the flight path of the object planned out in full detail and already know where it would end up in 5 years let alone fractions of a second later. The same formula would be applied regardless, making time irrelevant except for how much of it has passed since the last time you ran the update.If someone is still not getting it, think about collision detection. If you had an object that was 5 pixels wide traveling at a high enough speed, you might need to do an 'update' every 1/1000th second to actually see when it would collide with another very small object. This is a horrid approach. Instead, you should take all the variables into account, including when a collision would happen, and during each 'update' calculate what would have happened between the last update and the current one.In a multiplayer game, it helps greatly to just send a time stamp and the new input of an object (a player for example) and then during any update on any client, they would know right where the player should be (assuming no new update came along to change things).   