Hi, > > - int ticks_to_milliseconds(unsigned int ticks) > > While this function is- theoretically- valid, I don't think it _should_ be
As it turns out it's not being used so I'll take it out. Sorry, didn't notice that. > These also need a "sound server state" type as a parameter, since they > cannot access what used to be the sci0_soundserver() function's local > variables. Other than that, it's a good idea indeed to split up this > functionality into a bunch of functions. Yes, I was thinking about that. At the moment I'm just using static variables in a .h file which isn't appropriate of course. There doesn't appear to be a sound server state struct at the moment - if that's correct I'll add one. > Using a separate 'reverse stereo' function seems acceptable, too. > Note, however, that it should _not_ be the sound server implementation's > job to call each of these functions individually- usually, implementations > will be able to somehow determine one of the function constants defined in > soundserver.h, so this should happen in a function "process_action()" or > whatever that just consists of a big switch() statement calling these. That's correct. These are only called when a message gets sent to the event sound server, which hands it off to the appropriate function via a massive switch/if-else statement. As far as the polled sound server goes, I haven't looked at that. I was just going to put a call to the appropriate function whereever the actual code for that function currently is. > That sounds OK, as far as I can tell (with the caveats listed above, I > hope I haven't forgotten anything). As far as sound is concerned: I've > started working on an 'iterator object' style reader for songs, this > should help with cleaning up the sound code a bit more (and also to make > it easier to integrate with the SCI01/SCI1 sound resources later on). > The only new _functionality_ will be some experimental pcm > detection/reader code; up to SCI01, all PCMs are stored in sound > resources, so we might as well handle them in the sound server (might not > be the ideal approach, but that depends on what exactly the pcm interface > will end up looking like). Is this the Sample Dump Standard (SDS) detailed in the link to the MIDI spec you sent me? Also, several of the MIDI functions are not currently implemented (particularly the SysExs), I assume because SCI0 doesn't use them. Does this need to be done at some point? And another point, I notice that even under Linux the sound seems to be a little clunky. At least, it's not as smooth as the original Sierra games. Is there any known reason for this? Thanks, Alex.
