Message-Id: <199704232111.RAA02747@hcst.net>
From: "Bryan Murphy" <bf461 AT cleveland DOT freenet DOT edu>
To: <djgpp AT delorie DOT com>, "Shawn Hargreaves" <shawn AT talula DOT demon DOT co DOT uk>
Subject: Re: Measuring frame rate more often
Date: Wed, 23 Apr 1997 17:09:02 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Precedence: bulk

>IMHO a better technique is to just have the timer interrupt increment
>a global variable, and then have a main control loop along the lines of:
>
>    timer_variable = 0;
>
>    while (!game_over) {
>        while (timer_variable > 0) {
>            move_all_objects();
>            timer_variable--;
>        }
>
>        redraw_display();
>    }
>
>That handles changing frame rates, avoids all problems with reentrancy,
>and means there's only one little increment going on inside the
>interrupt...

I use a technique similar to this in my program.  I think this is genuinely
a 
better way.  If you have a really slow function running with the timer,
don't
you run the chance of slowing down the computers clock?  The nice thing
about this is that you can queue updates.  In my program, if it starts
getting
a bit hectic, the Updates will go over their time limit.  But, as soon as
whatever was causing the problems subsides, my loop recognizes that 
some updates were missed and hurries to catch up.  

I haven't tried it in a real useable situation yet, so I don' t know if it
might
be the source of problems, but since I'm using a Client/Server design, the
Client can smooth things out a bit.