[Openal] openAL float extension

[Chris Robinson]

On Thursday 03 May 2007 08:46:15 pm Will Rosecrans wrote:
> I'm curious to know what the logic was behind leaving this out of the
> core API?

In my uninformed opinion, I'd say it was because of the concept of K.I.S.S. 
(Keep It Simple, Stupid), along with the fact that floating point audio isn't 
really used for consumer-level stuff. 16-bit has been fine for more than the 
past 10 years. Especially for a new API, you don't want to be filling it with 
things people *may* use, only to find out that it could be impeding your 
progress later on (eg. "If only I didn't include X originally. Now it's 
making it difficult/impossible to do Y.."). As an extension, one could just 
stop supporting it. But as core functionality, it must always work.

> OTOH, in OpenGL you
> can use a texture in any number of formats without worrying if the
> graphics card supports drawing in that format.

Only to a certain degree. OpenGL does gaurantee some things when you select an 
internal format. For example, if you tell it to use GL_RGBA8 it will have at 
least 8 bits of red, green, blue, and alpha data. You may not have control 
over how it stores it (RGBA, ABGR, ARGB, losslessly compressed, etc), but 
you're gauranteed to have each component representable by at least 8 bits. 
Likewise, using GL_RGBA16FP gaurantees precision of at least 16-bit floating 
point (so-called "unnormalized data"), even if internally it could use 32-bit 
floating point. If the driver reports it, it must be supported, rendered with 
software, if needs-be.

So by comparison, if the OpenAL core spec required floating point formats, 
every implementation would have to support it, even if it can't be done in 
hardware. If a card had hardware mixing effects exposed through OpenAL, 
they'd have to work with floating point formats, or the effects would have to 
be implemented in software.

By leaving floating point formats out of the core, they enable implementations 
to be made for lesser-capable systems, while still letting capable systems 
work with it through the extension. Only when something has been shown to be 
very helpful and widely used should it be integrated into a core version.

Don't forget also, that there's few users that are capable of using hardware 
acceleration through OpenAL. On Windows, you have people with newish Creative 
cards, or wrapped around DirectSound3D. In Windows Vista, DirectSound is no 
longer accelerated, so that leaves only people with Creative cards. Other 
OSs, such as Linux and FreeBSD, have no hardware drivers for it at all, so 
everything has to be done in software for them. And for people like that, 
it's best to keep OpenAL accessible to let hardware support catch up.