About game loops.. yet again

[thekalkkuna]

Sorry if this matter has been beaten to death. I'm asking anyway =P. I couldn't actually find stuff related to this exact issue.

I'm pondering about the sort of game loop where the usually so called "update" is run at a constant rate and the view is rendered whenever possible. As I've understood it, it might happen that the frames are rendered faster than the world/physics/whatever is updated, in which case the frame would just render several times the same scene unless we interpolate (or extrapolate if we don't want to lag behind a maximum of one update interval) stuff with the value that represents the relative position (in time) between update ticks.

Now then, as I've no real experience about these sort of things, I was initially under the impression that the updating should take care of the world and the rendering is just a dumb imaging of it. Obviously when interpolating say a movement between the update steps, this isn't the case. If I have a moving object, do I then, in practice, have to sort of calculate twice (or more if update gets called more than once per draw) the new location of the object? First calculation round being the result of update, which is deterministic and in sync with everything and then the second round caused by the need for interpolation for the actual rendering only? This can't be right? I've got it all wrong?

Should it be like this, any suggestions or links as to how to design what actually gets interpolated in addition to being updated in the "world update"? Obvious answers are animation and transformations, and not stuff like AI decisions, but is there something else that should be considered?

[Nils Pipenbrinck]

You've pretty much described how it works:

Inside your game you have states that represent the transform of objects (rotation, location, scale ect). These states often come in two categories:

* Transforms that depend on the game dynamic, e.g. actors, cars, characters, everything simulated.

* Transforms that don't depend on the game dynamics: Static geometry, animations, maybe particle effects, glows around light-sources ect.

The trick is to run the first group in your simulation loop and you store the last two or three transformations. Use these to interpolate or extrapolate the transformation for any given time. This decouples your internal game update rate from the rendering frame rate.

All other stuff can be updated at the rendering frame-rate. Often the camera control for example is decoupled from the game itself. Think of an first person shooter: Does the game care where the player is looking at? In the shooters I played it made no difference, so I'd update the camera at the same speed as the rendering loop. This prevents the lag problem as the game seems to respond faster than it really does.

This is a simplified view. You may have to cheat here and there to make the game-world look consistent. In a race-game for example your extrapolation may occationaly push a car into a collision. If this happends it looks cheesy. You may cheat this if you detect such cases and move the car out of the collision geometry before you render it. The player will see the car at a different position than the physics simulated it for a frame or two, but for the game-play it does not make a difference.

The same applies for particle systems with collision and other things that interact with the geometry at higher speeds.

Hope it helps,

Nils