Re: time tutorial

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

Shadow Mint <shadowmint@mailcity.com> on 14/12/99 10:31:02

Please respond to linuxgames@sunsite.auc.dk

To:   linuxgames@sunsite.auc.dk
cc:    (bcc: Keith Lucas/Restricted/Cumbernauld/Atlantech)

Subject:  Re: time tutorial



Erik wrote:

> I finished up the tutorial I said I'd have done a couple weeks ago, it's
posted
> at http://math.smsu.edu/~br0ke/gamedev/timer/timer.html
> Take a look at it, critique it, tell me what I'm forgetting, where I'm
> wrong, and where I'm just a plain old idiot :) I'll try to squeeze it into the
> template after wednesday (finals). I guess it came out more like an article
> than a tutorial? *shrug*

I found that pretty interesting. Never thought 'bout it before. Alway just used
frames & synced 'em to try to ensure a consistant avg frame time. Anyway, just
one
little point confusing me: To calculate the time delta, would you need to
already
have done everything in that frame; so your physics/stuff calculated on the
"correct" lenth of the frame, would, in fact, be based on the previous frame's
size, no?

>Ie. Get time. Do all stuff. Get time. Get Delta (from diff). Get Time. Do all
>stuff (based on delta). Get Time... etc. Frame 2 uses frame 1 delta, etc.
>I spose if you went: Get time. Do stuff (eg. draw graphics). Get time. Get
>Delta.
>Calculate Physics/Etc. Get time. Do stuff (eg. use physics, etc.) Get time,
>etc.

This is what I do: I take the last timestamp and at the start of the physics get
a new timestamp. I compute the physics using that time difference and then do
the drawing (I spose I could do it the other way round, but it would be the
same? Would it?) and then save the timestamp for the next frame.

The picture you get is out of date. Very slightly out of date - not by much
though. It means if you move the pointer out of the window, I can pause the
physics, and simply restart it later - makes no odds if the time difference is
1/50th second or 50 seconds. (Actually there ends up being a alight
noticeability in some things, but they're only effects rather than essentials.
And the user has already broken reality).

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.

I also run a lot of things in elapsed time rather than iterated time: a shell
will follow an arc based on:  t = current time - time of launch, and then
application of s=ut+1/2at^2 where a=g, u=intial velocity. The ground impact can
be solved at launch, to put an end limit on the time (if the shell exists and
ground impact time is in the past, an explosion can be created at the ground
impact time. Note that if the frame is a long one, the death time of the
explosion may also have already passed and it will never be rendered...)

The shell path can be check against the move volume of vehicles in the
intervening time as well... basically it doesn't matter if the frame rate
plummets, everything stays on course. Knowing the max speeds of vehicles and
positions, I can work out if it's even possible to hit anything... and not
bother checking if the answer's no.