Re: Here it is!

[The Greene Family <topcoder@mindspring.com>]

Well, low-level maybe...but, the way my idea runs the programmers of games
have no worries at all...the user installs psound driver for his card and
the programmer of the game doesn't care because, all of the drivers work
the same way, just for a different card. 

   Btw, i mentioned nothing of music in that plan, but I _DO_ want to do
music.  Midi plans, are in my mind, i simply did not type them up yet.
(Although, I must honestly say, I dislike MIDI. :-)  

   I think you and I have the basically same idea.  I just didn't express
my idea correctly (that happens when one is tired and can't think straight
:-). 

    Hardware stuff I definitely want to use. OSS and ALSA I want to
interface, but, I would like for us to do our own hardware interface stuff
also.  

On the portability issue: As much as possible, I plan to keep PSound portable!

Derek

At 09:43 PM 3/28/99 +1000, you wrote:
> 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?
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: penguinplay-unsubscribe@sunsite.auc.dk
>For additional commands, e-mail: penguinplay-help@sunsite.auc.dk