Re: [Algorithms] Game loop timings

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

> frame of graphics. Thus, you'll do 0 or 1 frames of physics per frame
> of graphics. "N" in this case is 0.

Yes, you are right. Either N, N+1 or N, N-1, depending on how you look at N,
but never N-1, N, N+1. Correction accepted.

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

Hmmmmm.... have you tried locking the fps at e.g. 30 and forcing gfx to sync
to refresh (so you don't have screen tearing)? You should be able to see
stuttering on a steadily moving object in this situation (30fps vs 100Hz
physics, without interpolation). Screen tearing gives you a kind of "free
temporal antialiasing".

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

Console is one of the reasons tripple buffering is not an option. Hardcore
FPS gamers are another reason. Input-to-render latency and twitch games just
don't go together.

In a previous FPS project, I implemented fixed timestep for physics, AI,
controls and networking. It was simple and it worked. Used 20Hz for
timestep, interpolated the graphics. Everyone said the thing was very nice
and fast, and that it looks very, very smooth. Then we brought in a Quake
player who does competitions etc, to let him check it out. After a few
seconds running around, jumping like crazy and twitching the mouse
left-right, he said: "this is wrong". It took some time to figure out that
he is not happy unless I'm reading the mouse and moving the look direction,
once per _frame_. Seems like he is able to see (or rather feel) that there
is one additional frame that is rendered between the time that he changes
direction of mouse moveemnt and the time this effect is seen on screen.
After some training it was possible for others to discern this effect when
paying particular attention. Even though most people don't notice, those
that do seem to be particularly unsatisfied. :) With this particular
project, we went with fixed timestep, and just processed input and look
direction per-frame. But it was bit of a mess to handle. Moral of the story:
don't introduce latency where you don't have to.

> I would absolutely want to run the collider as often as the physics --
> else why run the physics that fast?

Perhaps it is not that obvious, but there are two reasons to run physics at
high rates.

1) Tunneling. IMO, solving tunneling by increasing physics rate is a bad
idea. To prevent tunneling, you need sweeping. Period. Integration
2) Articulated systems. For a simple example, rotation of a body connected
to another body by a ball joint, causes the ball joint to tear apart.
Explicit Euler integrator introduces large errors where angular movement
interacts with linear. So you need to keep the step size small enough to
keep the linear error caused by rotation under control and allow joint to
correct it. This is the primary reason for small timesteps. And it is
perfectly valid. But it has nothing to do with collision, and it can be
separated from collision rate.

So, I see a perfectly good reason to run physics at high rates, but none to
do so for collision.

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

Well, I can only say you are lucky. :) But that doesn't make it a generally
acceptable fact. Some people spend significant ammount of cycles per-frame
on AI. Duplicating that amount is not helping.

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

So, a rocket is going to explode at one timestep, and inflict damage to all
objects in range, and the damaged AIs are going to handle the damage event a
few timesteps later? A character is going to touch a platform for one
timestep, after which the platform is going to separate and the character
only gets to handle the touch event once he is again in the air, and has no
contact anymore? What if there are several successive collisions and
separations before AI gets that? Like all other problems, these are
solveable. But if you don't have them, you don't need to solve them.

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

Yes, of course. It requires some engineering to get around problems. But the
same stands for separation of AI steps from physics, inter/extrapolation,
NTSC/PAL networking etc, input latency, that appear as problems when using
fixed time step. :)

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

Of course. That really is The Easiest Way. But it has downsides. That is
good if you are doing a home project, if you are a newbie trying to make
your first game, if you are just prototyping something etc. And it can be
good for a real game, depending on the game type, target platforms, etc. All
I'm saying is that if you are going to do a real game with it, you need to
weight your requirements and see which is better for you, fixed or variable.

Cheers,
Alen