[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Here it is!



At 08:13 27/03/99 -0500, you wrote:
>	Constructive criticism is welcome, all out negativity is too. :-)  Feel
>free to call me an idiot and tell me I will never work on a Linux project
>again, that i need to rewrite, tha is rocks, or whatever.  I'll call this
plan
>draft 0.01 pre-alpha. :-)
>
>Derek
>Attachment Converted: "C:\EUDORA\ATTACH\psound.txt"
>---------------------------------------------------------------------

 I think that you are looking at penguinsound from too low a level.
>From my perspective, penguinsound should never need to worry about
what brand/type of soundcard is installed in the system. It should
simply use the existing drivers (OSS, ALSA, etc) in a common way that
is designed to make sound easy to do for a games programmer.
 So the game writer just writes to the penguinsound API, and the driver
takes care of using the most out of the underlying OS drivers. If the
low level system is nothing but a 8khz mono 8bit driver, then it doesn't
matter, the game will still work the same from the game writers point
of view. Our API should take the worry away from the programmer so he
can concentrate on writing a good game rather than figuring out how to
handle half a dozen different sound drivers, (or worse, a hundred
different types of sound card - this is back to DOS days!).
 It should provide most of the sound services that would be needed in
games. Games generally contain music & sound effects, so we need:
-a midi interface, and probably some capability for streaming music,
 such as mpeg or other types of compressed music. While I think of it,
 some way of interfacing to the CD-ROM driver to play audio tracks off
 a CD would be useful, as some games may use this.
 We also need suport for MOD/S3M/XM types of music. Peter Burns can
 contribute here (-:
-a software mixer, capable of mixing multiple sound effects, each with
 different frequencies, volumes & panning in realtime. Hardware mixing
 where available (eg GUS) should be used, but ideally the game writer
 shouldn't need to worry about this as penguinsound should take advantage
 of this kind of thing automatically (if this is feasable). This introduces
 problems like sample caching & so on, but I digress..

 Support for most common types of compressed audio should be included,
such as a-law/u-law, ADPCM, and mpeg audio layers 1-3. Whether these are
decoded in realtime or decompressed to raw PCM while loading (or a
combination) is something to think about. I can forsee music being
decoded (mp3/ADPCM) or mixed (MOD, S3M) in realtime, and game effects
being decoded when loaded so as to not overload the cpu when they are
played.
 Most of this stuff is pretty obvious, and has probably been said before,
but it never hurts to bring it up again...
 If the above is a bunch of hogwash, feel free to say so (-:

Errol

btw, exactly how cross platform is penguinplay (the whole thing, not
just penguinsound) going to be? I assume it is intended to cover Linux
on all platforms, but is it also intended to cover other Unix flavours
as well, and even windows, macintosh, BE or other operating systems?
The overview mentions porting to win95, so I assume we are aiming for
something both cross-OS, as well as presumably cross-architecture. No?