Timer library is library I did for timming in XaoS. But I found it usefull
in many other programs (like demonstrations, games, animation players and
all other stuff that needs to be timed). So you should read this description
and possibly use it in your application and save some coding time.
There is many ways how to design of such timed aplicatioin (game)
read user input, move badies, display and again
this way has one disadvantage. Speed of game depends on speed of computer.
This was acceptable in old times where only processor was Z80 :) but now
with wide variety of various hardwares such internal loop is unacceptable
read user input, measure time since last loop and caluclate step for
badies, move badies for set step, display and again.
This way fixes problem with speed. But moving badies just for caluclated
step, that should differ a much is quite complex, usually introduces complex
calculation, floating/fixedpoint math and other unnecesarry stuff that makes
program long and introduces many bugs.
Set the fixed framerate that is high enought to make game smooth but low
enought to do whole internal loop in time. So internal loop should look like:
read user input, move badies, display, meausre time spent in loop an
sleep rest of time until next frame.
This is quite popular scheme but has another disadvantage -- game can not be
designed to use whole cpu power since on slower computers internal loop should
take longer time that is reserved for one frame. Game will run slowly again.
To take away disadvantage of previous methot, many games times just
moving of badies and user input. Other stuff like displaying should be
done in rest of time. In dos games moving and user input is often at
asynchronous interrupt and drawing runs as main loop. This solves problem
in case that drawing of game takes significantly longer time than moving
of badies. This is quite usual so this scheme works well.
previous scheme still has one problem -- since timer interrupt works
asynchronously, there should happend many race condition, in case moving
takes longer time than time reserved from frame, computer can crash. So
this scheme should be enhanced into synchronous one with exactly same result
but avoiding problem with race condition:
read user input, measure time spent by loop and caluclate how many simulated
frame interrupts activated since last activation, if zero sleep until
simulated interrupt, move badies as many times as required, display
this is an combination of 4 and 3 and seems to be most confortable way
for writing games but since main loop is now quite complex many games don't
do that.
there is still one small problem. Method 5 expect that moving takes
significantly lower time that displaying. This may not be truth. Simple
work around is to write moving routine, that should move for x moves
by faster way that calling move x times. This is often possible and makes
easy extension to scheme 5. This scheme allows you to use very large
maximal framerate (say 100FPS) and to have same results as method 2
(that is maximally exact method)
As you can see, designing of main loop isn't so easy. This is just very
simple example. More advanced aplication for example should want to move
one set of badies at one framerate and other at different framerate. This
requires two such timmings. Another complication is that there is many
different ways to measure time exactly at different platforms. Under linux
you can measure using gettimeofday but under DOS this is exact just to 1/18
of second and thats too low for smooth animation and so on.
Thats why I decided to design portable easy to use timer library, that
makes easy to implement all described method, combining of them and much more.
During design I taken care at the following thinks: quality of timming,
how easy to use it is, speed, portability and to minimalize inexpected
situations (like race conditions in asynchronous interrupts and so on)
Please take a moment to fill out
this visitor survey You can help support this site by
visiting the advertisers that sponsor it! (only once each, though)
