Please, since this is pretty much off topic and to avoid arguments
please reply to me directly mailto:@Bob_Pendleton
I’ve started writing on article about the benefits of using SDL for game
programming. Please send me your personal experiences, and opinions, on
the value of SDL. If you tried SDL and decided that is wasn’t a good
choice, please tell me about it. I want to write a balanced, honest,
article about the value of SDL.
Many Thanks
Bob PendletonI would highly suggest you pick up a copy of "Programming Linux Games"
by John Hall. Find out more at http://www.nostarch.com/plg.htm it has a
lot of good information about SDL you could use.On Wed, 2002-07-10 at 09:52, Bob Pendleton wrote:
Please, since this is pretty much off topic and to avoid arguments
please reply to me directly mailto:bob at pendleton.comI’ve started writing on article about the benefits of using SDL for game
programming. Please send me your personal experiences, and opinions, on
the value of SDL. If you tried SDL and decided that is wasn’t a good
choice, please tell me about it. I want to write a balanced, honest,
article about the value of SDL.
Thanks for the suggestion. I’ve already skimmed through the book. What
I’m looking for is the experience and opinion of the rest of the community.
Bob P.
DrEvil wrote:> On Wed, 2002-07-10 at 09:52, Bob Pendleton wrote:
Please, since this is pretty much off topic and to avoid arguments
please reply to me directly mailto:@Bob_PendletonI’ve started writing on article about the benefits of using SDL for game
programming. Please send me your personal experiences, and opinions, on
the value of SDL. If you tried SDL and decided that is wasn’t a good
choice, please tell me about it. I want to write a balanced, honest,
article about the value of SDL.I would highly suggest you pick up a copy of "Programming Linux Games"
by John Hall. Find out more at http://www.nostarch.com/plg.htm it has a
lot of good information about SDL you could use.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-----------------------------------------+
I’m beginning to think John’s gonna need to write a second edition at this
rate. Besides the half-dozen buglets in the book (bet John knows exactly
where each of them is right now and has a d’oh for each), the book doesn’t
cover things like autoconf. Additionally, OpenAL is basically DOA. It’s
got positively no real force behind it anymore.
Other APIs have sprung up or been changed since the book was written too,
which will probably change how some things mentioned in the book are best
done.On Wed, Jul 10, 2002 at 12:07:10PM -0500, DrEvil wrote:
I’ve started writing on article about the benefits of using SDL for game
programming. Please send me your personal experiences, and opinions, on
the value of SDL. If you tried SDL and decided that is wasn’t a good
choice, please tell me about it. I want to write a balanced, honest,
article about the value of SDL.I would highly suggest you pick up a copy of "Programming Linux Games"
by John Hall. Find out more at http://www.nostarch.com/plg.htm it has a
lot of good information about SDL you could use.
–
Joseph Carter Now I’ll take over the world
Being overloaded is the sign of a true Debian maintainer.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020710/fe3c03bf/attachment.pgp
I don’t agree with this at all. If you were following the OpenAL devel
list you’d see that some big name gaming houses having chosen to use it
for their games. For example, Epic is using OpenAL for Unreal Tournament
2003 and they have obtained Dolby 5.1 certification from Dolby Labs. I’d
say that’s quite an accomplishment when using a “DOA” 3D Audio
Library…On Wed, 2002-07-10 at 13:29, Joseph Carter wrote:
I’m beginning to think John’s gonna need to write a second edition at this
rate. Besides the half-dozen buglets in the book (bet John knows exactly
where each of them is right now and has a d’oh for each), the book doesn’t
cover things like autoconf. Additionally, OpenAL is basically DOA. It’s
got positively no real force behind it anymore.
And we’ll see a Linux version of that when?
OpenAL is a standard developed behind closed doors with little
documentation and basically no serious interest in Linux at all. Oh sure
it runs there, but this only marginally significant given that there is no
real support for any of the 3D sound features in Linux.
And let’s not even discuss the braindamaged extensions in the Linux
reference implementation like incorporating mp3/vorbis libraries, courtesy
of Loki.On Wed, Jul 10, 2002 at 01:39:28PM -0500, DrEvil wrote:
I’m beginning to think John’s gonna need to write a second edition at this
rate. Besides the half-dozen buglets in the book (bet John knows exactly
where each of them is right now and has a d’oh for each), the book doesn’t
cover things like autoconf. Additionally, OpenAL is basically DOA. It’s
got positively no real force behind it anymore.I don’t agree with this at all. If you were following the OpenAL devel
list you’d see that some big name gaming houses having chosen to use it
for their games. For example, Epic is using OpenAL for Unreal Tournament
2003 and they have obtained Dolby 5.1 certification from Dolby Labs. I’d
say that’s quite an accomplishment when using a “DOA” 3D Audio
Library…
–
Joseph Carter <-- That boy needs therapy
emacs sucks, literally, not a insult, just a comment that its
large enough to have a noticeable gravitational pull…
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020710/f1275e15/attachment.pgp
cover things like autoconf. Additionally, OpenAL is basically DOA. It’s
got positively no real force behind it anymore.
'Cause you know, Unreal Tournament 2003 (and thus, all future Unreal
licensees) doesn’t use it or anything.
–ryan.
This is more the fault of the situation of Audio under Linux then of
OpenAL to a certain extent IMO. However, Creative is committed to
ensuring that the API’s don’t differ as much as you think they do. They
have been trying to work with people on “both sides” to ensure that this
does not happen.
Anyway, this is offtopic, reply directly to me if you wish to continue
this discussion.On Wed, 2002-07-10 at 16:06, Joseph Carter wrote:
On Wed, Jul 10, 2002 at 01:39:28PM -0500, DrEvil wrote:
I don’t agree with this at all. If you were following the OpenAL devel
list you’d see that some big name gaming houses having chosen to use it
for their games. For example, Epic is using OpenAL for Unreal Tournament
2003 and they have obtained Dolby 5.1 certification from Dolby Labs. I’d
say that’s quite an accomplishment when using a “DOA” 3D Audio
Library…And we’ll see a Linux version of that when?
OpenAL is a standard developed behind closed doors with little
documentation and basically no serious interest in Linux at all. Oh sure
it runs there, but this only marginally significant given that there is no
real support for any of the 3D sound features in Linux.
I’m really sorry for this off-topic reply about OpenAL, but I’ll keep
it brief.
OpenAL is an excellent API, even as it stands in the Creative Labs tree.
It was used to do a port of Freespace 2 to Linux, and I can tell no
difference between the audio in Linux/OpenAL and Windows/DirectSound3D.
It’s also fun (and easy) to implement 3-D audio into your games with.
Anyway, keeping it brief.
– chris (@Christopher_Thielen)On Wed, 2002-07-10 at 14:06, Joseph Carter wrote:
On Wed, Jul 10, 2002 at 01:39:28PM -0500, DrEvil wrote:
I’m beginning to think John’s gonna need to write a second edition at this
rate. Besides the half-dozen buglets in the book (bet John knows exactly
where each of them is right now and has a d’oh for each), the book doesn’t
cover things like autoconf. Additionally, OpenAL is basically DOA. It’s
got positively no real force behind it anymore.I don’t agree with this at all. If you were following the OpenAL devel
list you’d see that some big name gaming houses having chosen to use it
for their games. For example, Epic is using OpenAL for Unreal Tournament
2003 and they have obtained Dolby 5.1 certification from Dolby Labs. I’d
say that’s quite an accomplishment when using a “DOA” 3D Audio
Library…And we’ll see a Linux version of that when?
OpenAL is a standard developed behind closed doors with little
documentation and basically no serious interest in Linux at all. Oh sure
it runs there, but this only marginally significant given that there is no
real support for any of the 3D sound features in Linux.And let’s not even discuss the braindamaged extensions in the Linux
reference implementation like incorporating mp3/vorbis libraries, courtesy
of Loki.–
Joseph Carter <-- That boy needs therapyemacs sucks, literally, not a insult, just a comment that its
large enough to have a noticeable gravitational pull…
The biggest problem for me is no multiscreen. But, it’s open source, so
if I get enough time, I’ll add it myself, at least to my own SDL fork.On Thursday, July 11, 2002, at 12:22 AM, Bob Pendleton wrote:
Please, since this is pretty much off topic and to avoid arguments
please reply to me directly mailto:bob at pendleton.comI’ve started writing on article about the benefits of using SDL for
game programming. Please send me your personal experiences, and
opinions, on the value of SDL. If you tried SDL and decided that is
wasn’t a good choice, please tell me about it. I want to write a
balanced, honest, article about the value of SDL.Many Thanks Bob Pendleton
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Joseph Carter writes:
OpenAL is a standard developed behind closed doors with little
documentation and basically no serious interest in Linux at all. Oh sure
it runs there, but this only marginally significant given that there is no
real support for any of the 3D sound features in Linux.
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.
The point I really want to address is the documentation for openal is
freely available, on the web and in cvs. If you gave it even a
cursory look you’d have to concede that it complete and thorough.
And let’s not even discuss the braindamaged extensions in the Linux
reference implementation like incorporating mp3/vorbis libraries, courtesy
of Loki.
No, lets. I’m responsible for the extensions, not Loki, and I’m
fascinating to hear what second guessing you have for them. If my
suspicion is correct you are as uninformed on this subject as the
library in general.–
jv
OpenAL is a standard developed behind closed doors with little
documentation and basically no serious interest in Linux at all. Oh sure
it runs there, but this only marginally significant given that there is no
real support for any of the 3D sound features in Linux.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.
The point I really want to address is the documentation for openal is
freely available, on the web and in cvs. If you gave it even a
cursory look you’d have to concede that it complete and thorough.
Cursory look eh? How’s README for a start?:
OpenAL portable audio API.
See ./docs/index.html for more detailed information.
Okay, let’s do that:
This document has been removed. See www.openal.org for information.
The website (http://www.openal.org/info/) refers back to the CVS. There
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.
And let’s not even discuss the braindamaged extensions in the Linux
reference implementation like incorporating mp3/vorbis libraries, courtesy
of Loki.No, lets. I’m responsible for the extensions, not Loki, and I’m
fascinating to hear what second guessing you have for them. If my
suspicion is correct you are as uninformed on this subject as the
library in general.
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.
What, no libasound? hah. I know I saw code for that in CVS…On Wed, Jul 10, 2002 at 09:45:43PM -0700, jvalenzu at icculus.org wrote:
–
Joseph Carter Certified free software nut
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020710/f64e418c/attachment.pgp
Joseph Carter writes:
OpenAL is a standard developed behind closed doors with little
documentation and basically no serious interest in Linux at all. Oh sure
it runs there, but this only marginally significant given that there is no
real support for any of the 3D sound features in Linux.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 ).
Index
This document has been removed. See www.openal.org for information.
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
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.
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.
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.
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.
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!
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.
This is off topic, so I’ll be signing off. If anyone has any
questions or comments, I’m more than happy to answer them on the
appropriate forums.> On Wed, Jul 10, 2002 at 09:45:43PM -0700, @Joseph_I_Valenzuela wrote:
–
jv
–
Multiscreen or multiwindow. I’ve heard a lot of complaints about no
multiwindow capability, but this is the first complaint I’ve heard about
no multiscreen capability.
Thank You!
Bob P.
Andrew Straw wrote:> The biggest problem for me is no multiscreen. But, it’s open source, so
if I get enough time, I’ll add it myself, at least to my own SDL fork.
On Thursday, July 11, 2002, at 12:22 AM, Bob Pendleton wrote:
Please, since this is pretty much off topic and to avoid arguments
please reply to me directly mailto:@Bob_PendletonI’ve started writing on article about the benefits of using SDL for
game programming. Please send me your personal experiences, and
opinions, on the value of SDL. If you tried SDL and decided that is
wasn’t a good choice, please tell me about it. I want to write a
balanced, honest, article about the value of SDL.Many Thanks Bob Pendleton
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-----------------------------------------+
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.On Wed, Jul 10, 2002 at 11:43:06PM -0700, jvalenzu at icculus.org wrote:
–
Joseph Carter Available in cherry and grape
hehe, I really hate bug reports which are like calling fire
department and saying: “There is fire here, come!” 
(and hanging up)
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020711/07c67e59/attachment.pgp