Hi Alex,
> As far as I can tell, the options that have been suggested are:
>
> 1. Make everything highly generic by using song iterators to process every
> level of sound.
> - positive: very versatile
> - negative: maybe overkill at this stage
Hmm, I think I'll post my pro/contra arguments, too- maybe this'll help
clear up some things:
- positive:
Introduces abstraction layer needed for SCI1 music
Detaches song state handling from sound server processing
Externally timed sound iterators share exactly the code
they have in common with manually timed ones
- negative:
Will almost certainly break savegames
> 2. Have a new MCI-only sound server that bypasses the lower levels so they
> don't need to be changed.
> - positive: doesn't affect low levels
> - negative: no mt32gm mapping
- positive:
Can be implemented more quickly
Will not break savegames
- negative:
Ambiguates sound server semantics
Requires structual changes even though it's a hack (*)
Solves fewer problems
(*) Thus introducing dependancies on orthogonal code, which is a Bad Thing
(TM).
> Some form of (1) sounds like it will be required, but perhaps not so extreme
> right now.
I fail to see what's extreme about it...
Let me summarize: The current sound server/song decoding code is a tightly
coupled pile of crap (I can say that because I wrote most of the relevant
part, or am responsible for its design, at any rate). Song iterators are
one (IMHO quite clean) way to finally get rid of this cancerous growth
that's been bugging me for several releases, and we'll get a number of
other benefits for free.
OTOH, ambiguating the sound server semantics and introducing a hack that
waits in the sound functions -occasionally- is a huge architectural change
which will introduce the following problem:
With the same code base (sound server) being used for two very
different purposes (A, B), changes done to serve purpose A may affect B
adversely, or will need propagation to get to B (Only the latter is true
when using two completely(!) separate subsystems, which would be bad
enough already).
So much for MHO.
llap,
Christoph
