On Fri, Feb 09, 2001 at 12:22:21PM +0100, Christoph Reichenbach wrote:
> The handles usually map to objects in SCI heap space. 0x0000 might mean
> something special, but 0x75c0 is probably a bug of sorts- it might force
> the referenced object's song to be loaded, or skipped quietly in SCI, or
> something like that.
Well, given that it happens (0x75c0 or whatever) every time you leave
the text entry box, I'd think it is intended to un-pause the music
playing..
> - message transfers are expected to be atomic on read() or write(), but
> this isn't neccessarily true. This means that transferring sound
> commands, events, or even status messages may break during transfer.
> - message transfers use 'int's for some information. This defies one of
> the points of having a separate sound server (possibility of running
> it on a different system).
Ah, the joys of IPC. :)
So a new incoming event could interrupt one in progress? Wouldn't the
the shared pipe thingey implicilty enforce synchronization? What you
write to one end will always come out the same order on the other end,
and if it's in the middle of writing, say, 100k, a 5k transfer initiated
before the first one is over will wait until the first one is over.
Assuming that it's in the same execution thread, that is.. I'm not sure
how thread-safe some of the system calls are, but write() strikes me as
one that would be. :)
> Fixing both of these could be done simultaneously, and would clean up some
> of the things in sound.c and soundserver_null.c that ought to have been
> written differently in the first place.
How wold you have written the soundserver?
What are your feelings in scrapping the multi-process concept of
the sound server and making it threaded instead? That way we wouldn't
have to worry about transferring sound data, and having an event queue
would be pretty trivial.. (and what *nix doesn't have an implementation
of pthreads?)
I do think the concept of a seperate sound server is sound, but it would
really simplify things if it operated in the context as the rest of the
interpreter. Along the same lines, there wouldn't be a translation
between kernel events and sound events -- the queue would contain just
the kernel sound events, and the soundserver itself would do the
Hmm. I think I like where this line of thought is going.
(and that reminds me; I wonder how hard it would be to write a PC
Speaker driver? Certianly easier than a MIDI one..)
> Whoah- that's weird. Entering the player name works fine for me, BTW.
> The game freezing might mean that, somehow, you entered "menubar mode"
> (where the interpreter is inactive). Is this always the case for you, or
> only sometimes? Can you do other things in the player setup screen?
I wasnt' able to do anything then. But right before my laptop battery
tanked, I checked out a cleancopy of the tree devoid of my hacks, just
in case something was up. I'll test it when I get to work and see how
reproducible it is (and if changing the interpreter verion makes a
difference)
- 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"...
