Hi,
On Wed, 10 Jan 2001, Stuffed Crust wrote:
> How are sound effects handled? Are they just another midi "resource" or
> is it more like a "note on/note off" event pair?
Sound effects in SCI0 are MIDI tracks. In SCI01, support for PCM sound
effects were added (see Rickard's docs). SCI1 added a separate resource
file (resource.aud) for PCM audio data.
> If I understand this
> correctly, there's only one "song" playing at any given time, but any
> number of other higher-priority events can kick in, on top of or instead
> of the playing song.
Yes, that's IIRC what the system looks like.
> Now correct me if I'm wrong, but the sound code that's in place does
> little more than convert SCI0-->MIDI file -- there's no code to
> translate that file into a proper sequence of midi events to be sent to
> the device?
The code that is in place (in src/sound/) (as opposed to Rickard's code in
src/sfx/, which I still need to have a look at myself) does handle and
manage song data in a separate process, steps through the song data, and
sends events through a pipe when they occur. It just doesn't play them-
this might have been relatively simple to add, but, as Rickard pointed
out, the sound subsystem architecture needed a partial redesign.
(The stuff about "separate process" and "pipes" applies to UNIX only
(soundserver_null.c)- there's also a soundserver_dos.c, implemented (IIRC)
by Rink Springer, which "evaluates" MIDIs on request.)
> Or.. hmm. I suppose that's what the "MT32.DRV" or whatever did --
> DoSound(PLAY) tells the driver to add the contents of a resource to the
> conglomeration of running resources. Everything that's running is mixed
> in together, but if there are conflicts over channels, the
> higher-priority one takes prescedence. Or something like that.
I don't think things are mixed together in anyway- possibly in SCI01, but
not in SCI0. (There's a scene in QfG2 near the end, where background music
and combat music are playing simultaneously- I still don't know how
exactly that was done).
> ...the path is becoming clearer. Yay!
Great :-)
> Things I see that are immediately lacking:
> * _K_SOUND_VOLUME is, well, ignored. Needs to make the appropriate
> call to the sound server.
> * SOUND_COMMAND_SET_VOLUME and SET_MUTE need implementing. The FADE
> operation should re-use these anyway.
I'm not sure how much there is that needs to be changed in the way sound
is currently being called from the kernel, so it's possible that some
general changes need to be done for ksound.c.
> * A generic sound driver design needs to be drawn up. Richard's stuff
> appears to be mostly on the hardware side of things, and I think the
> majority of the tough work is in the middle, especially in sequencing
> the midi tracks.
You also need to handle persistance- we should be able to store the
complete state of the sound subsystem at any time and restore it later.
(Actually, I think SCI0 games restart music after restoring- they do
something rather similar with visual information- but being able to save
the game state at (almost) arbitrary points within the game is very
helpful for debugging. Also, I'm not sure if later SCI versions do the
same kind of "complete reset".)
> + Midi and Digital flavors
Actually, those can be handled separately, except where software
sequencers (like timidity) are being used.
> + lowlevel: init(), destroy(), setVolume(), sendData(), etc
> + highlevel: play_resource() (ie translate into midi/pcm), etc
> + [ideas, anyone?]
opional mt32->gm mapper :-)
> Then, once the framework's in place:
> * Create a soundserver_unix (do we really need more than one? Can't
> the OS-dependent nitty-gritty be in the lower-level drivers?)
There are two kinds of OS-dependant things we need to consider: Accessing
sound hardware, and running a concurrent thread of execution or process.
In between those two is, however, a lot of common stuff.
(Example:
a) soundserver_unix: sound.xxx -> MT32 MIDI -> MIDI events -> ALSA
b) soundserver_win32: sound.xxx -> MT32 MIDI -> MIDI events -> DirectSound
There's a lot of common stuff, obviously, and it's sandwiched in between
uncommon things.)
> Have it configure itself using ~/.freesci/config
> * Finish the mt-32 midi driver.
>
> I'm still on a rather steep learning and discovery curve, so bear with
> me as I try to get up to speed....
NP :-)
llap,
Christoph
