Re: Controlling Speed
- Posted by Robert B Pilkington <bpilkington at JUNO.COM> Nov 03, 1998
- 658 views
>This code has some shortcomings, I know... >1) What happens when the internal Euphoria time() function has to >reset to 0. This would seem to kill my delay() procedure immediately. RDS: >How big a number can time() return? I think it's 24 hours. I was running a screen saver I made using a delay routine like yours, and it hung after about 24 hours. (It was hung when I got back.) >2) This only works if the delay() procedure is imbedded into a main >loop that is executing constantly. It does not slow down a program unless >it is called relatively constantly. Most delay routines are like that, so I don't consider it a shortcoming. :) >3) Calling delay() just 1 time won't necessarily cause a delay. If >delay() is called milliseconds before last_time + delay_time will be > >time() then the procedure will not cause a noticeable pause. That's good for games: If the drawing/processing takes less than one clock tick (about .05 seconds at the default 18.2 ticks/second), then the framerate is set to 18 frames a second, just as long as the drawing/processing takes place anywhere less. If it takes longer, the game slows to half speed (or less, if the drawing/processing takes too long.). Here's my generic delay() routine: (Untested, written on the fly, but I use it!procedure tick_delay(integer ticks) atom oldtime for i = 1 to ticks do oldtime = time() while oldtime=time() do -- nothing end while end for end procedure tick_rate(30) -- include machine.e to get it. Sets framerate to 30, so -- tick_delay(1) will delay 1/30th a second, tick_delay(2) -- for 2/30th (1/15th), and so on. This line is optional, of -- course, if you want 18 frames a second. This way, even if the clock resets, oldtime will not equal time(), so the loop will continue. I think this is like the 3rd time I've mentioned this little routine... :) (One of them was to just one person, though.)