Re: [Algorithms] Game loop timings

[Alen L. <ale...@cr...>]

> > There is one big problem with fixed time step. If you are running on a
> > console, you will want to lock the frame rate to the TV refresh. So the
> > timestep has to be fixed at 60 Hz, or 30Hz. If it is 20Hz e.g, 0, 1, or
2
>
> First: if you pipeline your stepping and your rendering, it doesn't matter
> if you step N or N+1 times during a frame (you'll never step N-1 times);


Perhaps I am having a blind spot here, but from the intuition, and from some
past experience, I would say that if timestep is 20Hz and frame rate is
30Hz, you _will_ be doing N-1 steps. Am I wrong and why?

> this assumes that rendering uses slight extrapolation (or slight latency
> with interpolation).

Of course, as soon as timestep does not match or divide the frame time, you
need inter/extrapolation.

Anyway, doing N and N+1 steps will cause your frames to last longer on frame
with N+1 steps, hence you are wasting CPU on other frames. (This is only in
the worst case scenes, but it only matters in worst case scenes, because
when frame rate is fixed, you are wasting CPU anyway on an average scene,
but that is ok. You must optimize for the worst case, so it doesn't skip a
frame.) The only way to alleviate this is to split physics and rendering
into two threads and double buffer the world's state. Or if rendering was
allowed to lag at least one frame behind, as some PC drivers allow. But, due
to memory limits on consoles, both are usually not practical. And, both
introduce lag to your input. Deathmatch players hate that.

> I can see how, on a CPU-limited console, you'd want to run physics at a
> lower frame rate than graphics. However, for systems with fast-moving
> objects and massive, interactive physics, you really want physics
> stepped at rates of 100 Hz or more. Intel had a dual-core demo at GDC
> that used Novodex and stepped physics at 200 Hz; very smooth.

You definitely need to step the solver and integrator at more than 30Hz.
100Hz is usually good enough, yes. But:

a) Do you really want to actually move the bodies at this rate, and step the
collider? With there is an issue of AI and collision callbacks. Usually, it
is best if AI runs at the same rate as bodies move, otherwise collision
callbacks can get called more often than AI steps. Some tests for rockets
exploding on impact, jumping mechanics etc get a bit messy then.

b) Does this have to be _fixed_ timestep? It needs to be sufficiently small,
so that quickly rotating bodies and articulated systems can be solved and
integrated with less error. But there is no real requirement that it is
_fixed_.

What we do is to have timestep==frame and split it into an integral number
of substeps that are all of same size and _at most_ 10ms each. Collision and
AI run on each timestep, so the collision callbacks are synchronized with
AI, and much time is saved by not collisions on each substep. Solving and
integration is done per substep, but the bodies are not actually _moved_
until the end of the whole timestep. A sweep per object takes care that no
tunneling occurs, and the contact model is good enough to move bodies out of
any remaining interpenetration. This system runs at variable frame rates
without noticeable glitches. Additional bonus is that since solving and
integration is done per object cluster (or group, or island, or whatever you
call it), single objects that don't touch anything can be stepped without
substeps. Since a single object cannot produce enough numerical error to
require substepping. This saves a lot of CPU with projectiles, characters
most bouncing objects, etc.

Cheers,
Alen