On Tue, 11 Sep 2001, Stuffed Crust wrote:
> 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.
It seems we could keep the current method for the mostpart and satify
both polled and event-based implementations. After an event(s) has been
put on the queue we inline soundserver_process_events(), which can send a
message/signal for event-based implementations, or do nothing for the
polling-based implementations. process_events() could be a macro as well.
Maybe I'm repeating what Christoph just said, but I know for sure I'm
just ripping off what Sarien does in it's gfx drivers. ;>
> And even under Unix, we could just use good ol' SIGUSR1/SIGUSR2 :)
Doesn't some UNIX OSes have (relatively) high signal latencies? I remember
reading an article about this not too long agoo..
> 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...
This makes total sense, I fully agree.
--
http://www.clock.org/~matt
