[SDL] Re: SDL digest, Vol 1 #456 - 27 msgs
bogle at ihug.co.nz
Wed Jul 24 14:54:01 PDT 2002
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
> 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
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.
Joseph Carter <knghtbrd at bluecherry.net> Available in cherry and grape
<Dabb> hehe, I really hate bug reports which are like calling fire
department and saying: "There is fire here, come!" :)
<Dabb> (and hanging up)
* Dabb kills off dozen bug reports.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 273 bytes
Desc: not available
More information about the SDL