1. Timing
I was wondering if anyone would have an idea about how to set up a timer
to use in keeping the frame rate of a game constant.
possably using the same timer as in Jacque's "Delay.e".
it needed to be something like this:
procedure start_timer()
....Code
end procedure
function check_timer()
....code
return number_of_milli_seconds_passed_since_start_timer_was_called
end function
then i can have my game code as follows:
while still_playing = 1 do
start_timer()
update_game_objects()
draw_next_gfx_frame()
..etc...
while check_timer() < 4 do --4 miliseconds = 25 Fps.
--Waste time to slow frame rate
end while
end while
it needs to be pretty quick, because at the moment i'm doing the same
thing but using time(), but it seems to degrade the performance of my
program. giving me 18-19 fps instead of 20.
any help would be cool.
-Mark,
Liquid~nitrogen Software.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
2. Re: Timing
- Posted by Robert Pilkington <pilking at BELLATLANTIC.NET>
Jan 08, 1999
-
Last edited Jan 09, 1999
Here's my method:
tick_rate(25) -- Clock updates 25 time per second
procedure delay()
atom oldtime
oldtime = time()
while oldtime=time() do -- Wait until clock updates
end while
end procedure
while still_playing = 1 do
update_game_objects()
draw_next_gfx_frame()
..etc...
delay()
end while
The only problem with this method is that if the game loop takes more than
1/25th a second (or whatever tick_rate() is set to), then delay() will wait
until the next clock update, slowing the game down to half for that frame.
A better method would be some kind of frame skipper, that doesn't draw the
frame if calculating took to long, and skips to the next frame. (Like 3d
games nowadays do.) But I don't know how to do that... Anybody care to show
us? 
3. Re: Timing
Mark,
Basically I do not trust your mathematics skills 
. You wrote:
> while check_timer() < 4 do --4 miliseconds = 25 Fps.
The rate of 25 frames per second corresponds to 1/25 = 0.040 s, which
is obviously 40 milliseconds per frame!
So I decided to check your performance degradation claim, and it too
seems to be highly exaggerated.
ON a 266 MHz P II machine under Windows I get one million time()
calls in about 0.7 s, less than one *micro*second per call! Even on a
typical 486 system I would not expect more than about 10 microseconds
per time() call. But your 1 to 2 fps performance degradation claim
would imply (at 20 fps) about 5 to 10 *milli*seconds loss. Not bloody
likely! jiri
ps bonus: If you need just a rough, quick timer and, for some reason,
cannot use the time() function the following works:
integer tfm -- ticks from midnight
tfm = peek4u(#46C)
Unfortunately, the tick rate at this location is *not* affected by the
tick_rate() routine, so you are stuck with the standard 18.2 ticks per
second using this shortcut...
4. Re: Timing
My previous note on the subject was totally negative. Since today is
just another pleasant ripper of a day in a long succession of
beautiful summer days down here at the arse end of the world (sorry,
not my words - a former Australian prime minister is credited with the
expression), I suppose I can also afford to be a little bit more
positive.
First of all I'll show you what I usually do (warning: this is
unlikely to benefit anybody who is not at least as stupid as I am):
constant dt=0.04 -- desired time interval per frame (25 fps)
atom t1,t2
tick_rate(100)
while 1 do -- frame loop
t1=time()
...code to generate a frame...
t2=time()
while t2-t1 < dt do t2=time() end while -- waste time
end while -- end of frame loop
Which is admittedly not terribly bright... The code below is how I
*now* think it should be done:
t1=time()
while 1 do
t2=t1+dt
...code to generate a frame...
t1=time()
while t1<t2 do t1=time() end while
end while
The whole point of it is, that only *one* time() call is made when the
things are tight... jiri
