I've been thinking about the best way to implement physics, collision checking etc. properly, and it seems that fixed rate would make the calculations easiest. On the other hand video framerate can't always match the physics, so that would give my some twitchiness in animation.

So is there a one best way to solve this conflict, or many solutions with their own tradeoffs? Any help is welcome.

Am I just begging for a brian fellows answer?

The best (in my opinion) way is to have a fixed physics timestep. Then, each time you update your main loop you advance the physics system until it just goes _beyond_ the "system" time. Then for each physical object interpolate between it's current and old position/orientation, based on the system and the physics time, and use this interpolated state to render.

If you do this you can run your physics system at a low frequency - e.g. 30Hz - assuming it's stable, and your game looks really smooth even if the frame rate is high. If you don't interpolate then you can get jerkiness due to irregular numbers of physics updates per frame, and due to the fact that even with a high framerate objects don't necessarily move every frame (especially a problem if your camera isn't synced to the physics system).

Hi,

Physic integration and framerate is a tricky problem.

The easy solution always seems to use a fixed timestep. It makes your game quite predictable and your physic more robust. However this has a few caveats that can become nightmares. If you assume your physics is updated at a contant rate your logic will be someting like this :

while (!Gameover)
{
Update();
while (PhysicTime

Thanks for interesting points. I've been thinking about possibility of demo recording and playback too, so it seems that fixed timestep should be the way to go?

You could reckord the deltatime of each frame, so fixed step physics is not a requirement for playback.