[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: time tutorial



Keith Lucas wrote:

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

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


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

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