Re: [AD] proposal: al_sleep() |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Sat, 2004-01-03 at 15:59, Chris katko wrote:
> >I don't see the reason why 100% CPU usage is bad.
>
> and
>
> >I still can't think of any Allegro program where I would want to call
> >yield_timeslice
>
> I actually use yield_timeslice() in my app. It's a level editor, and without
> a yield, it eats winamp's timeslice so much that winamp fails to keep up
> it's rendering.
Yes, of course. I always used yield_timeslice or in recent times
something equivalent to it myself. I should have said, any program where
I would prefer the current yield_timeslice over the behavior I think it
should have (which it has on some platforms anyway, which it has in my
1st patch, and which al_sleep(0) has in my 2nd patch).
> So, yes, it does come into play. At least when using tools.
> 3dsmax for instance, only takes 100% cpu when rendering, otherwise, it plays
> nice with everything else.
Yes. That's exactly how I think Allegro apps should behave. With the
current yield_timeslice, Allegro uses always 100% CPU - even if it does
nothing. The new al_sleep will hopefully change this. Your level editor
could just use al_sleep(0) then instead of yield_timeslice, so
additionally to allowing other programs to run like with yield_timeslice
- it would also use only as much CPU as it actually needs. My first
patch - which changed yield_timeslice so it uses Sleep(1) instead of
Sleep(0) - caused all the Allegro examples I tried to use much less CPU.
> One more thing, has anyone considered that having different wait times
> per-OS could cause problems? I mean, if you had a crossplatform networked
> game, and one copy waits 10ms, and one waits 25ms, couldn't that be a
> problem? I'm not sure. Maybe it should be noted that they don't wait the
> same per-OS.
>
Well, it depends on how you implement it. Either allow different rates,
or have a fixed rate. The game logic then will have to deal with it. In
both cases you must be prepared that some packets may be delayed. The
user might have opened another window, or there might be network
congestion, not to forget that the transfer itself might take several
ms.. so you always have to be prepared that packets don't arrive at the
exact time something occurs at the other end.
Another way I have seen used in the network library GNE is to use a
separate thread, which calls select or something equivalent, and let the
OS wake it up whenever there is a network event. There it then can put
the events into a queue, and handle in the game loop. (Of course, since
Allegro has no user visible synchronization facilities or threading
functions - it's quite hard to implement yourself, without using such a
library.)
Anyway, I think being able to have Allegro apps not use up all available
processor power (in a cross-platform way) will be a big improvement :)
--
Elias Pschernig <elias@xxxxxxxxxx>