RE: [Algorithms] Game loop timings

[Jon W. <hp...@mi...>]

> > 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?

The time-stepping and the frame-drawing work in phase similar to the
Bresenham line drawing algorithm, which goes N items over before it
goes one item up (which would be the N+1 case). In the case of 20 Hz
physics and 30 Hz drawing, though, that would be similar to trying to
draw a line with a slope steeper than 45 degrees, because you can't,
on average, even do one step of physics in the time needed for one
frame of graphics. Thus, you'll do 0 or 1 frames of physics per frame
of graphics. "N" in this case is 0.

> > 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.

With a good enough physics timestep, you don't need to. Physics at 100 Hz
and "free running" frame rate around 25-35 (depending on machine/card/etc)
seems to work just fine in my tests.

> 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.

You're assuming that graphics and physics are not pipelined. I'm assuming
that you triple-buffer your graphics, which will compensate for the
jitter. If you're on a console, you might not have that option, which
might make you take another approach.

> 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

I would absolutely want to run the collider as often as the physics --
else why run the physics that fast? I don't do a lot of AI, and the AI
I've done is high-level, goal-setting kind of things plus very low-level,
force-producing kinds of things (which can integrate into physics
constraints) so I haven't seen a problem with AI cycle consumption.

> 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.

Rockets exploding and jump behavior typically goes into the "physics
constraints" category, and need to be locked to the frame step to feel
good.

> 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_.

It is possible to engineer stable, consistent, re-playable, networkable
physics systems without jitter, using a variable time step. But life is
too short :-)

> 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.

If it works well for you, it's obviously what you want to do :-)
However, my experience has been that there's less pain and better
feel in high step rates and collision/forces being at the same step
rate as physics, and significantly better behavior with a fixed
time step. So, if someone's asking me "how do I do this" then I'll
probably keep saying that "the easiest way I've found is ..."

Cheers,

			/ h+