On Sat, Jan 19, 2002 at 05:15:56PM +0100, Christoph Reichenbach wrote:
> Hmm, that's why the original song iterator concept had iterators for
> device translation, too.
Ooo. I see. I think I need to dig through the archives some, then.
> Yes, I know it's easy for me to like my own ideas, but avoiding the sound
> server overhead on systems that don't use it seems like a worthwhile goal
> for me- otherwise, you'd need a fake sound server to accomplish the same,
> and two classes of output drivers. This works, too, but I think it's
> unneccessarily complicated.
The soundserver is rather heavyweight, but the alternative so far seems
to be "reimplement the wheel" for each platform. Of course, that seems
to be happenning anyway.
But the actual song decoding is only a small part of what the
soundserver does. The real work is getting events from the main game,
passing them back, and then performing the timing/sequencing to get the
notes to play back correctly.
So it seems that the "soundserver" isn't going away, it's just getting
renamed with a slightly more generic interface.
We should integrate the current song_iterator ASAP (if for no other
reason to have the song parsing code in one place)
Then re-work the translation layer to more cleanly fit with the grand
scheme of things. Then again, will thre be anything other than the
mt32->gm translation? Do we really need a formal translation interface?
Aside from the mt32gm driver, everything else is a straight
SCI_midi->native_device affair.
- 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"...
-- Attached file included as plaintext by Listar --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8SapdysXuytMhc5ERAgTwAJ9fJUAl4nfLtVNNB90nsCW9aytRBwCfaQAl
coGm0/jypHLoSn82UXs/uWQ=
=GUxP
-----END PGP SIGNATURE-----
