Re: [Algorithms] Formula for Damping f times

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

Richard wrote at 6/9/2009:
> I'd say that you have to aim for 100% repeatable with a physics model
> that is meant to be part of a network game, but for non multiplayer
> games you could get away with it.

Hm, I'd say that "100% repeatable" would mean "can repeat the exactly
same results when re-simulating from exactly same inputs, no matter
for how long the simulation lasts". For most network games you will
have some server synchronization anyway, and what is needed there is
just "approximately the same results when resimulating from exactly
the same inputs, for some shorter period of time". A packet comes in
from the server every once in a while and corrects eventual
inconsistencies anyway. Granted, for some platforms and gametypes, you
want to use full lock-step, and then you need 100% repeatability.

> However, what do you benefit from variable time step apart from
> reduced CPU time on tasks? Not much I'd say.

Exactly that. Reduced CPU time on AI, collision and physics. And not
just reduced, but more scalable. And that is very important. Fixed
time step leads to situations where a slower machine gets even slower.
What would be the spiral of death, unless you limit the longest frame
possible, but even with the limit, a slower machine is non-linearly
slower than a faster machine.

E.g. let's say one step takes 1ms to process on machine A, and 5ms on
machine B. At the same time, rendering takes 9ms on A, and by
extension 45ms on B.

So with variable timestep, X runs at 1000/(1+9)=100fps, while Y runs
at 1000/(5+45ms)=20fps. Let's say you want to fix the timestep at
50Hz. X still runs at 50fps, while poor Y is now at around
1000/(5*3+45)~=16.7fps. Plus the fact that X now has some
interpolation and some input lag (this is 20ms lag in local actions,
which a skilled deathmatcher will notice). Of course, this is
oversimplified, but I hope it illustrates the problem.

I'm not saying that you can let everything run at any rate. Some
things (ragdolls, e.g.) may require step subdivisions, as they cannot
really run at 10Hz. But forcing everything to the same rate is
prohibitively expensive on slower machines, if the physics is intense,
IME.

> What you gain from fixed time step, fixed point math, or at least
> repeatable math, is the ability to debug your model.

Doing it both ways, my experience is that the amount time you save by
simpler debugging due to repeatability, is completely overwhelmed by
the amount of debugging needed to keep the repeatability. So I'd say
you choose fixed time step on the basis of whether you really need _so
exact_ repeatability for networking, not just for simpler debugging.
If you can get away with _mostly repeatable_ and resync every once in
a while, you life is definitely simpler.

JM3C,
Alen