Re: time tutorial

[Shadow Mint <shadowmint@mailcity.com>]

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.
You'll mostly get rid of it. But you'll still continually be losing time in the
Calculations section, which is not really significant, might eventually lead to a
synchronisation failure if networking events are based on real time values (not
frame values) which you'd have to do if you that 'cause the frame sizes would be
inconsistant over the net.

*thinks for a moment or two* ... But then again, I spose you could do a manual
clock, which only runs during frames or something & base net events on that.
Anyway, ignore me, just rambling. Good article. Two things: 1) Maybe an example of
an application other than "This is a delta" would be handly, 2) It's plain text &
boring as all hell. Try seperating it into paragraphs & add a =) picture or two.
It'll add 150% to readability.

Cheers,
Shadow Mint.