On Tue, Sep 11, 2001 at 11:34:30PM +0200, Christoph Reichenbach wrote:
> 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.
I like this better from an architecural perspective, but implementation
will be more difficult. The main game loop shouldn't care about asking
the soundserver for events. Fortunately, the amount of work that the
"signal handler" has to do is quite small; generall just a matter of
updating a couple of variables in the heap.
> 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.
And even under Unix, we could just use good ol' SIGUSR1/SIGUSR2 :)
> I guess we have a plan now, except for the first issue (leave API polled /
> take advantage of events).
I vote for making it a event-driven API. The main game loop should know
nothing of soundserver signals coming in. OS-specific event handlers
will perform all updates to the heap asyncronously.
We also hae to keep in mind that we'd like this infrastructure to
support PCM audio/events as well. But SCI really doesn't make the
distinction, so I guess it doesn't really matter.. One thing I'd like
to do is get rid of the whole "song transfer" and have the soundserver
itself load the sound resources off of disk. with PCM data, transfers
can get quite large...
- Pizza
--
Solomon Peachy pizzaATfucktheusers.org
I ain't broke, but I'm badly bent. ICQ# 1318344
Patience comes to those who wait.
...It's not "Beanbag Love", it's a "Transanimate Relationship"...
