(Chopped most of this, because Tyler's got a lot of good points...just
wanted to throw out some corrections on small points.)
the time, OpenAL 1.1 was available on Windows, OpenAL 1.0 was available
on OS X, and OpenAL 0.8 was available on Linux (in fact,
http://www.openal.org/downloads.html still reflects this).
The version string in the Linux version is really misleading; it's been
1.0 compliant for a long time (although 1.1 was a different story).
Now I will say that the situation has improved a bit so far in 2006.
OpenAL 1.1 eventually found it's way to the unstable Debian repository
(along with freealut) so now I am on the cutting-edge. However, the
truth remains that across many systems, OpenAL remains an older and
out-dated library.
For what it's worth, we can't help that Debian isn't really a
bleeding-edge sort of distro. :)
For UT2004, we just shipped our own copy of the library...for open
source things, you can always just tell people to upgrade their
packages...sooner or later, you'll have to anyhow. You wouldn't spend
time worrying about whether your game works on glibc 0.9, after all.
the programmer using the API), it turns what should be one of OpenAL's
greatest strengths into one of its greatest weaknesses!
This is a fair point, but I always looked at this as cross-platform in
that it's something you can target and ship on every platform, not
something guaranteed to be installed by default.
the documentation. For example, I discovered that on some machines I
could only create 16-64 sources, while on others I can create as many as
I like.
(I thought this was documented now...never assume that alGenSources()
has an infinite supply, and always assume that it's rather small. I also
thought we guaranteed at least X number of sources.) There was a time
when this definitely wasn't documented, though.
--ryan.
|
| 
