Hi,
[Separated architecture]
> Pros:
> * more flexibility with sound drivers
> * some sound drivers might have advantages or better features than others (this
> could be a con)
> * song decoding done apart from event control so this aspect does not take up
> CPU usage in-game
This is a moot point. Decoding songs doesn't take much CPU time, and
there's little difference between this happening in the program and this
happening in the OS, in general.
> * simpler on individual platforms
> Cons:
> * complex in overall design, leading to a (relatively) long time to implement
> and with complexity comes harder to find bugs
Note that almost all of our current code can be re-used, so after
migrating the sound servers to this design, we could add new features
incrementally.
> * somewhat scatty - UNIX would use playmidi, Win32 would use DirectMusic, etc..
Don't see this as a problem.
> * results from different MIDI player programs on different platforms is more
> unpredictable
This is a problem with General MIDI in general, and something we can't fix
without limiting ourselves to timidity or similar solutions.
> * lose some control by using MIDI player software?
This is only an issue for fade-outs, which we wouldn't be able to do
cleanly on systems without a mixer (which, in turn, isn't present on all
systems). Could be emulated by stopping the sound player process and
re-starting with the appropriate song fragment (ouch).
> * leave it up to the operating system to control both FreeSCI and MIDI player
> (this could be a pro)
IMHO it's neither.
> * may get out of sync with animation, particularly looking towards the future
> if we did have a cross-platform game environment as James recently suggested,
> where *any* (poorly written) SCI game could run
> * may not get much of a performance improvement
> * may need to split up songs at cue points as well
As Solomon pointed out, this would get ugly.
llap,
Christoph
