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

Re: time tutorial



On 14-Dec-1999 Shadow Mint wrote:
> 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?
> 

yeah, the size of the time frame is based on the previous frames size, but
between frames there is very little change in the size of the frame. Some games
might have huge differences between FPS speeds, but they don't snap from one to
the other in a single frame, and my eyes aren't good enough to catch a small
quirk lasting less than .03 seconds (30 fps of change in one frame). Since a
real clock is being queried, it all balances out in the end...

> 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 would slaughter any kind of normalization you get, the time to do physics
might take .002 seconds while the screen draw takes .01 seconds... 

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

Network communication is a seperate issue, and different games use different
methods. I beleive qw uses a delta method with occasional absolute values to
make sure it's not deviating. The entire reason for using this method is so you
can address the world using 'seconds' instead of 'frames' as a unit of time.

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

1) I was considering this, but the method is so primative that I don't want to
give an example where people thing it's only for that, and I don't want to tie
myself to a specific OS/library set, as it can be used with any library set or
os... I might make a glut app *shrug*

2) it is seperated into paragraphs, I even have paragraph indentation, which is
pretty uncommon for 'net documents... unless your browser doesn't obey  
mebbe I should put blank lines between the paragraphs *shrug* The only thing
that could possably fit would be a flow chart, and seeing two circles or
squares with edges both directions between them isn't the most interesting
thing to look at... I don't see how pictures can help present the material
better?

> Cheers,
> Shadow Mint.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.auc.dk
> For additional commands, e-mail: linuxgames-help@sunsite.auc.dk
> 
> 

        -Erik <erik@smluc.org> [http://math.smsu.edu/~br0ke]

The opinions expressed by me are not necessarily opinions. In all
probability, they are random rambling, and to be ignored. Failure to ignore
may result in severe boredom or confusion. Shake well before opening. Keep
Refrigerated.