Re: time tutorial

["Keith Lucas" <klucas@atlan-tech.com>]

>> If any single frame glitches, or there's a bit of a swap frenzy or whatever,
the
>> very next frame everything comes back into true: There's no averaging over
>> frames or catching up, it simply snaps to the true state.

>*woa!*   Neato. I didn't think of that. So no matter how fast the computer is,
it
>can accomadate it, and make it run right,
>and even a small frame glitch can be over looked.
>
>*grins* right. BRB. I'm changing my code. =P
>
>Cheers! =)
>SM...

There are some "be carefuls"... firstly, you don't know how long a frame is. You
can't work out where the shell ought to be now, see if it should have died and
explode it, because that might be a long way underground... you have to do the
interpolation.

There are some things that need special handling. Muzzle flashes, for example,
need to show up for a frame, even if it's long past their death (otherwise
you'll not see them). However, you want to ensure only one is drawn per weapon,
regardless of how many times in the frame the weapon fired.

You have to make some decisions: If you have an automatic weapon, that fires
every 1/10th second if SPACE is held down, you have to decide what to do if
space is down and the current frame is 2/10th second long: do you fire once and
set the "reload" time to the past or do you fire twice. The first means the
weapon will stutter, the second means the player may waste ammo. If you're
running 2 threads, you can solve this, because one will be event handling from
the keyboard, and you can create two "fire requests", time stamped 1/10th second
apart. The game physics which is in another thread can compute the player
locations at those times and create the shells or whatever next time it does a
physics cycle.

There is an adantage in clamping the game physics. The drawing physics (things
like particles)  you want to run every frame. The game physics, stuff like
responding to keypresses, you /could/ do every frame, but there's not actually a
huge need any more. You could in fact do sections of it each frame... Or run it
in a lower priority thread.

{For the current thing, we're running the game physics on a seperate process,
possibly in a seperate machine.}

Also: Mario is running along, and something slows the process. The player hits
"JUMP". If the jump is executed at the END of the physics interval, Mario might
have run off the platform. At the BEGINNING and he might miss the next platform.
What to do? It might in fact not suit this sort of game at all: this kind of
game might benefit from stalling the whole game for a fraction of a second and
then picking it up again.


Generally the trick is to be careful, think twice and code twice (second time
around is always much better code). Go at it slow and careful; there are more
places to trip up than in frame clamped stuff.


>*nods enthusiastically* I see exactly what you mean. It's a much better way to
go.
>;)
>Thanks for drawing my attention to it!

There is another cool feature of this: if you've got vector classes designed
properly, the code looks like the physics equations, so it's instantly readable.