SDL_opengl.h problems

SDL Development
#1

Hi!

I’m using an extension in my program now and because of that I’m now using
SDL_opengl.h to include the neccessary headers. On Windows this is no
problem, but some linux users reported that this doesn’t work for them,
because the definition of the extension is missing. It also seems to be
releated with the nvidia opengl headers. Can this easily be fixed, or do I
just have to copy out the definitions for the extension into my own header
and include GL/gl.h and GL/glu.h manually again? What’s the purpose of
SDL_opengl.h then?
If someone wants to take a look, the problem is in PrBoom 2.2.3, get it here
http://prboom.sf.net

Florian

#2

Could it be that the extension is linked statically? The users gets a
redefinition of the extension. I’m doing the definition like this:
PFNGLCOLORTABLEEXTPROC glColorTableEXT;
And then load the extension with SDL_GL_GetProcAddress.
How can I detect this when compiling? I guess there is some define for this.

Florian> ----- Original Message -----

From: @Florian_Schulze (Florian Schulze)
To:
Sent: Tuesday, July 30, 2002 10:12 AM
Subject: [SDL] SDL_opengl.h problems

Hi!

I’m using an extension in my program now and because of that I’m now using
SDL_opengl.h to include the neccessary headers. On Windows this is no
problem, but some linux users reported that this doesn’t work for them,
because the definition of the extension is missing. It also seems to be
releated with the nvidia opengl headers. Can this easily be fixed, or do I
just have to copy out the definitions for the extension into my own header
and include GL/gl.h and GL/glu.h manually again? What’s the purpose of
SDL_opengl.h then?
If someone wants to take a look, the problem is in PrBoom 2.2.3, get it
here
http://prboom.sf.net

Florian

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

#3

Could it be that the extension is linked statically? The users gets a
redefinition of the extension. I’m doing the definition like this:
PFNGLCOLORTABLEEXTPROC glColorTableEXT;
And then load the extension with SDL_GL_GetProcAddress.
How can I detect this when compiling? I guess there is some define for this.

This looks right, what’s the exact error message?

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

#4

Here is the bugreport:
https://sourceforge.net/tracker/?func=detail&atid=103396&aid=588392&group_id
=3396
The other guy who reported this bug discovered that his SDL_opengl.h was too
old.

Florian> ----- Original Message -----

From: slouken@devolution.com (Sam Lantinga)
To:
Sent: Tuesday, July 30, 2002 7:58 PM
Subject: Re: [SDL] SDL_opengl.h problems

Could it be that the extension is linked statically? The users gets a
redefinition of the extension. I’m doing the definition like this:
PFNGLCOLORTABLEEXTPROC glColorTableEXT;
And then load the extension with SDL_GL_GetProcAddress.
How can I detect this when compiling? I guess there is some define for
this.

This looks right, what’s the exact error message?

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

#5

Here is the bugreport:
https://sourceforge.net/tracker/?func=detail&atid=103396&aid=588392&group_id
=3396

This bug report looks like it’s not related to SDL at all… it looks like
a conflict between prboom’s gl_intern.h and the NVidia headers.

The other guy who reported this bug discovered that his SDL_opengl.h was too
old.

Cool, I guess the problem is closed.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

#6

Here is the bugreport:

https://sourceforge.net/tracker/?func=detail&atid=103396&aid=588392&group_id

=3396

This bug report looks like it’s not related to SDL at all… it looks like
a conflict between prboom’s gl_intern.h and the NVidia headers.

Yes and no, because the line which causes the problem is this:
PFNGLCOLORTABLEEXTPROC glColorTableEXT;
And the parse error is the PFNGLCOLORTABLEEXTPROC part. You said in a
earlier mail that this line seems to be correct. I don’t understand the
conflict. It seems like glColorTableEXT is already defined in the NVIDIA
headers, so how do I fix this conflict then?

FlorianFrom: slouken@libsdl.org (slouken)

#7

Here is the bugreport:

https://sourceforge.net/tracker/?func=detail&atid=103396&aid=588392&group_id

=3396

This bug report looks like it’s not related to SDL at all… it looks like
a conflict between prboom’s gl_intern.h and the NVidia headers.

Yes and no, because the line which causes the problem is this:
PFNGLCOLORTABLEEXTPROC glColorTableEXT;
And the parse error is the PFNGLCOLORTABLEEXTPROC part. You said in a
earlier mail that this line seems to be correct. I don’t understand the
conflict. It seems like glColorTableEXT is already defined in the NVIDIA
headers, so how do I fix this conflict then?

Hmm, looking at the error message, it looks like PFNGLCOLORTABLEEXTPROC is
not defined by NVidia’s headers. I’m not sure that SDL can or should do
anything about that.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment> From: “Sam Lantinga”

#8

Hmm, looking at the error message, it looks like PFNGLCOLORTABLEEXTPROC is
not defined by NVidia’s headers. I’m not sure that SDL can or should do
anything about that.

Can I do anything about it? Maybe checking if PFNGLCOLORTABLEEXTPROC is
defined? I haven’t looked, but I think that it is a typedef and those can’t
be checked with an #ifdef. I’m really lost with this currently.

FlorianFrom: slouken@libsdl.org (slouken)

#9

Hmm, looking at the error message, it looks like PFNGLCOLORTABLEEXTPROC is
not defined by NVidia’s headers. I’m not sure that SDL can or should do
anything about that.

Can I do anything about it? Maybe checking if PFNGLCOLORTABLEEXTPROC is
defined? I haven’t looked, but I think that it is a typedef and those can’t
be checked with an #ifdef. I’m really lost with this currently.

You might be able to make the prototype yourself. If your prototype matches
the official one, then the compiler shouldn’t complain about a duplicate
typedef.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment> From: “Sam Lantinga”

#10

coughdyngl3cough

I find it truly astonishing how many people are dead serious when they
tell me there is no reason to have or use something like DynGL 3 and that
it is silly for me to have put so much work into something like it. And
yet, every time I see someone with problems using OpenGL headers or
linking to OpenGL libs for their SDL programs, I realize that I have seen
all of these problems before either on my own system or users of Twilight,
the project for which DynGL 3 was created. Once we started using runtime
OpenGL binding, these problems and a host of others like it suddenly went
away.

For this and other reasons, I think SDL 1.3 should include a variation on
the model of DynGL as part of the API - and the standard/preferred way to
use OpenGL in SDL. Yeah it means a bunch of function pointers, but then
again that table of pointers would exist anyway with ld.so or similar
mechanism anyway. Plus we already know that SDL can easily cope with this
because it provides the core subset of the DynGL 3 functionality in the
1.2 API - and in fact relies on that functionality internally.

The only added overhead which would come from adding all of DynGL’s
features to SDL directly is the extension management. Primarily, DynGL
has a function to check for the existance of an extension in an OpenGL
extensions string. It goes a step further, however, by checking for
drivers which lie - claiming to support an extesnion and then neglecting
to actually implement some or all of the functions that extension
requires! I’ve seen segfaults from this in programs which do not check
for extension function pointers being NULL after checking the extension
list.

DynGL 3 implements this by splitting the extension list string into an
Amiga-style list (which is a bit hackish by C standards but nonetheless is
quite clever), but it could be implemented just as easily by adding a
generic bool-returning function which finds an extension in a supplied
extension list string. Note, this would be wise to have anyway just to
keep people from foolishly using strstr which cannot tell the difference
between EXT_foo and EXT_foobar… The idea here being that if the lookup
for an extension fails, the extension is added to a "bad extensions"
blacklist string. A convenience function (or even macro for that matter)
would let you check that the extension is NOT in the blacklist AND is in
the OpenGL extensions string.

Note, I’m not asking for SDL to maintain a full OpenGL 1.4 specification
in a header full of function macros, complete with extensions and all.
No, I suggest providing a small one (basically enough for the NeHe and
GameTutorials type things) and giving people the option of using their own
local header which they can include before SDL_opengl.h which provides all
of the macros they need. It’s not realistic to ask you or anyone to
maintain a full OpenGL macro list. It’s also not realistic to declare the
at least 600 function pointers that would be required to support OpenGL
1.4 plus everybody’s extensions. But it is not really sane to depend on
sometimes hostile OS vendors (thanks Microsoft) to provide a sane OpenGL
development platform. DynGL doesn’t use libGL.so/opengl32.lib at all -
nor for that matter does it even use GL.h or its various abnormal namings
(thanks Apple…) It also doesn’t depend on the Linux vendors to follow
the Linux OpenGL ABI and place their OpenGL libs in /usr/lib and only
/usr/lib (thanks XFree, Debian, and anybody else who is apparently unable
to read the f**king ABI document!)

Okay, I’m done ranting for now - are you convinced yet or should I rant
more? =)On Thu, Aug 01, 2002 at 02:18:11PM -0700, Sam Lantinga wrote:

Yes and no, because the line which causes the problem is this:
PFNGLCOLORTABLEEXTPROC glColorTableEXT;
And the parse error is the PFNGLCOLORTABLEEXTPROC part. You said in a
earlier mail that this line seems to be correct. I don’t understand the
conflict. It seems like glColorTableEXT is already defined in the NVIDIA
headers, so how do I fix this conflict then?

Hmm, looking at the error message, it looks like PFNGLCOLORTABLEEXTPROC is
not defined by NVidia’s headers. I’m not sure that SDL can or should do
anything about that.

–
Joseph Carter I N33D MY G4M3Z, D00D!!!111!!
(Just … don’t ask)

oh noooo, Knghtbrd’s got a gun :slight_smile:
^^insert music^^
bfextu - o/~ everybody is on the run o/~
o/~ run away, ruuuuun away from the pay-ay-ain o/~

-------------- 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/20020802/fb0a74b6/attachment.pgp

#11

Just tell me where I can get DynGL 3 and how I can use it, then I’ll be
happy.

Thanks,
Florian

#12

http://icculus.org/twilight/release/dyngl3-0.zip

dyngl.c should explain more or less how to use it. Note that all OpenGL
functions are prefixed by q. Example, glColor4fv becomes qglColor4fv. We
do this because the qgl namespace is already used for this by Quake 2/3,
making it essentially forever safe to use. The functions are all
documented as to when to call them and such.

If you understand how SDL handles OpenGL, this works the same way… It
just has more types of function macros is all:

DYNGL_NEED (void, glBegin, (GLenum mode))
DYNGL_WANT (void, glDrawRangeElements, (GLenum, GLuint, GLuint, GLsizei,
GLenum, const GLvoid *), Alt_glDrawRangeElements)
DYNGL_EXT (void, glDrawRangeElementsEXT, (GLenum, GLuint, GLuint, GLsizei,
GLenum, const GLvoid *), “GL_EXT_draw_range_elements”)

The first is a required function - the program will not run without this.

The second is a function whose nonexistance is nonfatal. In this case,
glDrawRangeElements - not always available, but nice enough to use when it
is. The last parameter to the macro is the name of an alternative
function which implements the missing function, or NULL. Note if you use
NULL, you can shoot yourself in the foot.

The third is an extension. (The function Alt_glDrawRangeElements will
use glDrawRangeElementsEXT if it’s not NULL or fall back to lesser means
if it must…) Self-explanitory.

There are no docs except those in the code. The dglfuncs.h file contains
only those functions used by Project: Twilight, not those which are useful
for tutorials or other projects - I intend to do this at some point, but
you’re quite welcome to beat me to it if you like. =)

Basically, you make sure dyngl.c gets compiled in to your project and you
include dyngl.h in place of SDL_opengl.h. Then right after you open your
OpenGL context, call DynGL to have it get all of your function pointers.

In lieu of real docs, please feel free to ask me if you have any questions
with it.On Fri, Aug 02, 2002 at 12:11:56PM +0200, Florian Schulze wrote:

Just tell me where I can get DynGL 3 and how I can use it, then I’ll be
happy.

–
Joseph Carter <-- That boy needs therapy

<Apple_IIe> anyone seen my 80 column card?

-------------- 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/20020802/39062ae7/attachment.pgp