Please change the title when you change the subject.
Bob Pendleton
Joseph Carter wrote:> On Wed, Jul 10, 2002 at 11:43:06PM -0700, jvalenzu at icculus.org wrote:
I hate pointing it out but gaming on linux is a margin market anyway.
I doubt you’re serious about addressing what support for “3D sound
features” but I can say that having a solid software renderer was and
is my goal with the linux reference implementation.Great - if you want a 3D sound API for two speaker systems. Meanwhile, 4
and even 6 speakers are supported by several drivers now.Guess what. 4 speaker sound is supported by linux openal, via
extension ( I’d like to take the moment to credit Chris Purnell
for this and several other excellent patches. He was criminally
removed from the CREDITS file during the various cvs root changes
but has been re-added ).Then I apologize for not noticing this. I know about Chris’s work on
OpenAL, but did not see him mentioned anywhere. Much of my annoyance with
the Creative/Loki tree was that it did not use Chris’s bugfixes or his
four-speaker support - he had tried to get his changes into Loki’s tree
earlier. I can guess then that his changes were incorporated into the
short-lived icculus tree?www.openal.org. API Information. Daily snapshot. Were you really
confused? You were even provided a link. I’d say you failed to
provide a cursory effort.The website (http://www.openal.org/info/) refers back to the CVS. There
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^I’d say you failed to read my message before you started flaming. That
IS the API information link you accuse me of failing to go to.are SGML docs, but these total a mere 7300 lines total for the entire
library, in pretty-printed SGML source code. How you document 15 megs of
source code completely or thoroughly in 7300 lines of mostly markup is
beyond me. I know enough to write a simple mixer able to handle 8 sounds
for two channels with independant volume and attenuation, but I can’t
follow what is in the documentation directory.Indeed, if you claimed to be able to follow what was in a documentation
directory I’d be very surprised. You’ve shown no ability so far.You’ve shown no consideration of the possibility that the documentation
could somehow be confusing, possibly incomplete, or otherwise in need of
correction. You refuse to even consider the concept that the README needs
an update to actually point someone to real documentation rather than a
pointer to a pointer to a page which says the documentation is in CVS
(which it is, if you can follow it…)The documentation is available in HTML for those of us who have
never been able to get SGML to work ( sadly guilty of that myself
). Annotated versions are included to determine reasoning behind
api decisions.You’d rather assume that I haven’t even seen the SGML (I had not seen the
HTML, but I find it now that I know the link “daily snapshot” has nothing
to do with CVS…) I can read the SGML just fine. Follow what I’m reading
though? That I could not do so well. I’ll go back and read that chapter
of John’s book again though, it’s been more than a year since I actually
tried to use OpenAL in a serious application.I still believe the SGML documentation (which includes everything the
annotated HTML docs include - I’ve checked) is not very clear, and is
missing fundamental concepts. That or there’s something I Just Don’t
Understand about the API. In either case, I think it could stand to be
improved.And I can point out that each api decision was open to public
discussion, with requests for comments. Several comments lead to
major changes in the API. This contrasts with the process for
other open source libraries, which have had less public comment or
insight into their design. The effort that Bernd committed to the
design of the API - including soliciting comments, questions,
suggestions from potential users - was beyond reproach.I do not question these practices. I stayed out of the discussions
because I knew very little about sound coding at the time. I know enough
to mix sixteen sources with volume and attenuation to stereo sources now,
but don’t claim to actually be much of a sound person. I can do this
because I’ve seen and understand code which does this, and could reproduce
it, not because I have any fundamental understanding of sound processing.Maybe I haven’t got the background to use OpenAL then, but I certainly had
less background in graphics when I started learning OpenGL. I’d expect a
similar learning curve.Does the word “bloat” mean anything to you? It’d be one thing if we were
talking about hardware acceleration here, but we’re talking about extra
dependencies on half a dozen libraries to add support for mp3 and vorbis
in software as part of the reference implementation. OpenGL is useful
because it is simple, well documented, and reasonably self-contained. So
far, OpenAL is none of these things! In fact, the package available for
my dist depends on libaudiofile, libesd, SDL, SMPEG, and libvorbis.The extensions are entirely modular, so bloat is a red herring.
The dependencies are on a per-extension basis - so if you don’t
want to install libvorbis, libaudiofile, libesd arts or whatever,
don’t enable the extension. I’ve never really understood the
philosophy that code reuse is bad anyway. What’s the alternative?
Put an entire copy of smpeg and libvorbis into openal? Just so
people don’t have to type --enable-smpeg? I don’t have any interest
in maintaining an mp3 decoder.The mp3 decoder should be my problem to worry about, not yours. If I want
mp3, I would have to worry about which decoder to use, whether or not I
wanted it static or dynamic, whether I’d include it with my binaries for a
given arch or not, etc. I don’t like external deps much, as list archives
will plainly tell anyone. I don’t like them to the point that I wrote a
whole mechanism to handle dynamic OpenGL binding to ensure that the
program built regardless of how screwed up your vendor’s OpenGL dev stuff
is.I’d rather not have to do the same with OpenAL, especially given that
currently SDL does not export the functions which are needed to do this
from its API. (They’re trivial for Win32 and free UNIXes, but it’s still
better left to SDL for portability reasons…) Kudos to whomever is
responsible for making alcGetProcAddress be guaranteed to work on all
functions, rather than just extensions as OpenGL.And there’s nothing stopping you from implementing your own decoders
for these formats. Then you can sit in comfort and introduce the
exactly same dependencies you just eliminated by selecting a
configure option. Yay!If I don’t want them, I shouldn’t have to worry about them. I’m stuck
worrying about them anyway.I hope it’s obvious by now that your criticism is based largely on
ignorance and misconception. The API is simple, amply documented
and if it does not meet your criteria for self containment, at least
it is modular. I guess it’s lost on you that many of the extensions
are in alut, not al.My criticisms are based on what I can see in CVS and on the website. I’m
not infallible (I did not know that Chris’s patches were finally accepted
after more than a year of him maintaining a fork he didn’t want, and I
guess widespread Linux support will happen if widespread win32 support
does) but simple and amply documented I still contest, if for no other
reason than that if such were the case I should not have nearly as many
problems trying to find out how to do anything useful with the library.
–
±-----------------------------------------+
- Bob Pendleton, an experienced C/C++/Java +
- UNIX/Linux programmer, researcher, and +
- system architect, is seeking full time, +
- consulting, or contract employment. +
- Resume: http://www.jump.net/~bobp +
- Email: @Bob_Pendleton +
±-----------------------------------------+