Hi,
> So to combine all that Christoph...
[...]
OK. This still leaves the issue of how to combine the event-driven and the
polled sound servers. IMHO, the "more compatible" solution would be to
make it look like a polled architecture on the outside (leaving the
interface to the SCI kernel unchanged), and catch the messages/enqueue
them inside (server->main). The alternative, calling a message function in
the main process (if I understand it correctly, this is a bit similar to
invoking a signal handler function in UNIX in behaving like an implicit
function call from whereever the program counter happens to be in the main
process, i.e. it is executed while the main process is sleeping and
operates on the memory and system ressources assigned to this process)
would behave more like Sierra SCI in processing the event right after
it was emitted. This would involve messing with the the sound->kernel API
in no-opping the polling functions and explicitly calling the message
handlers, but should work and actually give (theoretically) better results
on event-based systems.
On the other end, splitting up the sound server into process_message() and
process_sound() (as suggested) and calling it from a polling loop (which
could probably even be implemented generically, thanks to Pizza's
abstractions) for polling servers/calling them directly from event-based
systems seems like the way to go.
I guess we have a plan now, except for the first issue (leave API polled /
take advantage of events).
llap,
Christoph
