Re: [Algorithms] Game loop timings

[Kent Q. <ken...@co...>]

I agree with Tom-Tom.

Fixed physics rate is definitely the way to go. Consider what happens 
when you pause the game, or run it in slow motion, or the user switches 
to a different app for a while and your frame rate goes wacky because 
another process needed attention. In all those cases, you accumulate 
error and things explode. It's quite amusing to switch away from the 
game, switch back, and find yourself in a completely different country 
because you just moved 13 kilometers in one time step.

I once spent quite a while implementing a variable rate clock that tried 
to redistribute lost error over a number of ticks, or throw out errors 
when they got too big. There were all sorts of interesting bugs for 
weird cases, and even when those were fixed, you still didn't have 
reproduceable physics.

Switching to a fixed step physics clock dealt with all of that very 
nicely. What I didn't do, but should have, was what Tom suggested below, 
which is interpolating between physics clock ticks so that your physics 
doesn't have to be tied to your frame rate at all.

    Kent


Tom Forsyth wrote:

>>I would disagree with TomF's assertion that variable framerates
>>are easier.
>>    
>>
>
>Wait - let's be clear about this. What I said was:
>
>"Fixed-time-increment _rendering_ is hard for the reasons Chuck mentioned.
>But having your internal game state update at a fixed increment, or
>multiples thereof, is not. A lot of games do it, and it removes a lot of
>problem with reproducibility of results. Having your game change behaviour
>between debug and release, or just by maving the camera, is not a good
>thing."
>
>So since we're talking about AI, then that's internal game state, or
>"gameplay" or whatever you want to call it. I 100% agree that should happen
>at fixed timesteps.
>
>But the _rendering_ should just happen as fast as it can happen, and you
>interpolate between the current game state and the previous one. That way if
>you're simulating at 24Hz (which is surprisingly common, simply because a
>lot of animation systems run at that speed!), but rendering at 30Hz, the
>interpolation copes with the fact that you have slightly fewer game turns
>than frames.
>
>  
>
>>My take on this, given the behavior as you describe it, is that
>>you just need to separate yourself somewhat from the concept of
>>"real" time.  Time is what you decide it is, so there's no harm
>>keeping it at 1/20th of a second if indeed your target speed is
>>20 fps.  As long as all of your updates are consistent, and as
>>long as everything uses the same value, it should be fine. 
>>What you want to avoid, and what you're doing, is accumulating
>>error and then cutting out the error whenever it accumulates
>>big enough, despite what the actual frame times might be. 
>>Instead, just don't worry about the error.  You want the
>>apparent time passed to be pretty consistent with the actual
>>time passed, otherwise you'll get jerky motions.
>>
>>I would disagree with TomF's assertion that variable framerates
>>are easier.  I think the fixed per-frame time is significantly
>>easier to code up and put into play.  Personally, I prefer
>>variable time if you are truly running at arbitrary framerates,
>>but on the platforms I work on the timestep is always going to
>>be 1/60th of a second or some multiple thereof.  When the
>>framerate cuts from 60fps to 30, then all of the timesteps are
>>magically larger.  Note that this change may be significant,
>>though, and it may then be desirable to run two 60Hz updates
>>instead of worrying about missed collisions etc. that may start
>>appearing when your timestep doubles.
>>
>>One problem I thought of the other day is that typically I've
>>implemented and used systems where the timestep that is used is
>>the time that it took the last frame to render.  Unfortunately,
>>that means if our framerate is really jittery, on a
>>frame-to-frame level, we'll get really jerky motion.  E.g. if
>>we literally alternate 1/60 and 1/30 second frames, then we're
>>rendering actions that should be separated by 1/60 of a second
>>1/30s apart, and also rendering things that should represent
>>1/30s only 1/60s apart.  Is this fear rational?  In practice
>>probably not, since our framerate is going to be relatively
>>consistent frame to frame, but still...  Hmm...
>>    
>>