Re: [AD] rest and yield_timeslice

[Elias Pschernig <elias@xxxxxxxxxx>]

On Sun, 2004-07-18 at 12:49 -0700, Chris wrote:
> Angelo Mottola wrote:
> > True, the rescheduling will make it loose some milliseconds. But we 
> > stated nowhere rest() is meant to be used for accurate timing. When you 
> > need accurate timing, you'd better stick with Allegro timers.
> 
> Allegro's timers are just as accurate as a system's sleep function, if 
> not less so. In fact, IIRC the timer thread system sleeps when there's 
> nothing immediately waiting to run, so you end up getting a resolution 
> of about 10ms per timer function call (which can be called multiple 
> times to catch up, if needs be).
> 
> And true, the docs don't say that rest should be used for accurate 
> timing, however I don't think that should automatically give us the 
> liberties to make it more innacurate than it has to be.
> 

Well, we follow the semantics of Sleep(), select/usleep, SDL, and
properly most other waiting functions out there. And we won't get less
inaccurate than before, since it actually was using a timer everywhere
util now except windows.

> > Again, rest() is not meant to be used in an inner game loop. Timers are 
> > meant for this.
> 
> The timers are, at most, just as accurate as system sleep functions. The 
> only way to time more accurately than this is to busy loop with a high 
> accuracy timer, for which Allegro doesn't provide a cross-platform way 
> to do so. As well, this has the obvious disadvantage of not lowering CPU 
> usage.
> 

Well, if you send a patch to add an al_get_ticks functions which is more
accurate than timers, I'd be all for including it. I've often seen code
to use clock() or Win32DirectXGetPerformanceTimerTicks or something like
that in Allegro programs, so a function for that really should be added.

> > And we could do this:
> 
> I personally would prefer:
> void rest(long time)
> {
>    if(time <= 0 || !timer_driver)
>      return;
> 
>    timer_driver->rest(x);
> }
> 
> And the driver's rest method wouldn't have to worry about platform 
> dependant rest 0 behavior, or add an extra check for <= 0, since the 
> rest function itself does it.
> 
> > But then you'd be fool to call rest(0) since it does nothing.
> 
> You might not necessarilly know ahead of time. Like in my example, if 
> you do 'rest(expected_time - actual_time);' you won't immediately know. 
> It could even come out negative. You'd have to add an extra check, which 
> would, IMO, be pointless since Allegro would do its own check as well.
> 

Yes, but from my view, where rest() is primararly there to give up CPU
for a certain amount of time, yielding behavior makes perfect sense for
0 as parameter. Your user above would be better off using a busy loop,
at least for small wait times. Negative values to rest will be catched
by an ASSERT in rest, or even better, I'll make the parameter unsigned.

> 
> > I was 
> > suggesting to merge the functions because rest(0) has no real meaning 
> > currently, and because I wanted to reduce slightly API clutter...
> 
> rest(0) does have a perfectly valid meaning. It means to rest for 0ms, 
> or as close as possible. And as well, yield_timeslice has been a part of 
> the API since pre 4.0, so I don't think it can go anywhere for a while. 
> You'd end up having two ways to do the same thing, which is a bit worse 
> than a little clutter for a couple things that behave slightly different.
> 
> Remember.. rest gives up the CPU as a side effect, not as standard 
> behavior. AFAICR, the docs have never said anything about rest giving up 
> the CPU as normal behavior.
> 

We are trying to clean up the API though, at least a bit, for 4.2, and
Allegro has had some very bad design decisions already long before the
3.x versions - so that's never a reason to keep inconsistent or
unnecessary functions. We even deprecated the perfectly useful textout
functions. And I'd even go as far as fixing things like the 0..63 value
range for RGB in 4.2.0. Deprecating yield_timeslice is nothing compared
to that :)

-- 
Elias Pschernig