At 6:04 AM -0700 5/27/99, Dave Lippincott wrote:
>You are only guaranteed an event every x cycles if you set EvtGetEvent, not
>just nilEvent. If your app requires a nilEvent every X seconds, be sure to
>pass a value to EvtGetEvent that is a multiple of your required interval.
That does work, but it can also mean your 'idle' process can start as late
as 1/n of the interval, where n is the multiple you use above. That is, if
you want events every second, but pass a timeout of 1/2 second and it
happens to be .0001 seconds before your interval would have expired, then
you could end up delaying nearly 1/2 second past your update time.
If you're doing a clock and want the seconds indicator to look good, then
it's not so bad. Trial and error says if you pass a constant timeout of
1/4 second (25 ticks on the device) it looks smooth. That is, even if the
seconds counter is 1/4 second late, no one notices.
On the other hand, if you want to run 10 frames a second for a game, you
need to get smarter.
It's not too hard to keep a variable that has the tick count when the next
idle event should be processed. You subtract the current tick count
(TimGetTicks) from this value to get the timout for EvtGetEvent.
Then you don't test for nilEvents at all, instead each time through your
event loop you compare the current tick count to your global, and if it's
higher, do the animation processing and update the global.
That is, your event loop looks like this:
EvtGetEvent(..., max(0, nextIdleTime-TimGetTicks()));
// no matter WHAT the event is, always check for the "heartbeat"
if (TimGetTicks() >= nextIdleTime) {
DoAnimation(...);
nextIdleTime += sysTicksPerSecond/10;
}
switch(event) {
...
}
See Roger's "Reptoids" app for an excellent example.
--Bob
