www.delorie.com/gnu/docs/xaos/xaos_39.html   search  
 
Buy GNU books!


An fast realtime interactive fractal zoomer

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.5 The timer library

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)

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

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

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

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

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

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


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

  webmaster     delorie software   privacy  
  Copyright 2003   by The Free Software Foundation     Updated Jun 2003