SDL_GL_GetProcAddress bug and a humble request

SDL Development
1

As it turns out, you can’t depend on SDL_GL_GetProcAddress to return the
function with some broken (Win32) drivers at the moment.

Basically, some wglGetProcAddress implementations (3dfx) can’t return
non-extension functions. And to complicate matters, the native Win32
function may not work on extension functions since the driver may export
only one function name, but return the same pointer for various requests
when you use wglProcAddress.

So:

wglGetProcAddress (“glBindTexture”) <-- fails for 3dfx

GetProcAddress (hInst, “glLockArraysEXT”) <-- fails for TNT

Lovely, innit? I haven’t got time to completely implement the fix now,
but here is the rough fix for this purpose:

func = NULL;
if ( video->GL_GetProcAddress ) {
    if ( video->gl_config.driver_loaded ) {
        func = video->GL_GetProcAddress(this, proc);
        if ( !func ) {
            SDL_LoadFunction (video->GL_Handle, proc);
        }
    } else {
        SDL_SetError("No GL driver has been loaded");
    }
} else {
    SDL_SetError("No dynamic GL support in video driver");
}

Basically, if the normal allocation method fails, try to get the symbol
the hard way. If that fails, you’re screwed. Note, as I’ve done this
here, you will need to add GL_Handle to SDL_sysvideo.h - I didn’t see
something similar in there.

I wish I could provide a real patch right now, but I am a bit busy working
out a decent smarthost arrangement so I can send mail to the SourceForge
projects I am part of. You see, VA Software has decided discrimination
against connection classes is effective spam prevention. They have told
me their position is that the users unfairly blacklisted as spammers are
an acceptable cost, and if my ISP sucks too much to rely on their
smarthost then I should get a better ISP - regardless of how much more
that will cost me. They feel dialup block blacklisting is at least as
effective as active scoring spam detection tools such as spamassasin, and
while they plan to install specifically spamassasin, the DUL blacklisting
will probably continue.

This means I can’t even control my own projects. I’m quite fed up with
the attitude of VA Software in recent months, the evil-looking usage
policy changes, the cronjobs that crash several times a day, the long PR
resolution times (and the number of PRs resolved as “we won’t fix this”),
and in general the whole mess. I’m looking for alternative hosting, and I
can provide a smallish server for the task if there’s someplace to put it.
I would ask Ryan about icculus.org, but SSI has some commercial ambitions
even if all of our code is GPL, so I feel somewhat uncomfortable taking up
his bandwidth with something that may one day down the line be returning
us some measure of financial profit.

I originally had planned to try and pay for some hosting, but I was hoping
to not need to worry about that until after that potential financial
return came in so I could afford to do so. ;)–
Joseph Carter No conceit in my family

That reminds me, we’ll need to buy a chainsaw for the office. “In
case of emergency, break glass”

-------------- 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/20020515/43b1c240/attachment.pgp

2

Basically, some wglGetProcAddress implementations (3dfx) can’t return
non-extension functions. And to complicate matters, the native Win32
function may not work on extension functions since the driver may export
only one function name, but return the same pointer for various requests
when you use wglProcAddress.

So:

wglGetProcAddress (“glBindTexture”) <-- fails for 3dfx

GetProcAddress (hInst, “glLockArraysEXT”) <-- fails for TNT

Yes, this is on my todo list to fix for SDL 1.2.5

Thanks,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

3

Please make this highish priority if you can Sam, it’s a nasty thing.

It’s this or get you to export the hidden LoadLibrary functions in the
1.2.5 headers so I can actually load the GL library myself… =pOn Wed, May 15, 2002 at 10:35:18PM -0700, Sam Lantinga wrote:

Basically, some wglGetProcAddress implementations (3dfx) can’t return
non-extension functions. And to complicate matters, the native Win32
function may not work on extension functions since the driver may export
only one function name, but return the same pointer for various requests
when you use wglProcAddress.

So:

wglGetProcAddress (“glBindTexture”) <-- fails for 3dfx

GetProcAddress (hInst, “glLockArraysEXT”) <-- fails for TNT

Yes, this is on my todo list to fix for SDL 1.2.5

–
Joseph Carter Sooner or later, BOOM!

rcw: Oh yay—I haven’t been involved in a good flamewar in at
least … 5 minutes!

-------------- 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/20020516/616fee5c/attachment.pgp

4

Basically, if the normal allocation method fails, try to get the symbol
the hard way. If that fails, you’re screwed. Note, as I’ve done this
here, you will need to add GL_Handle to SDL_sysvideo.h - I didn’t see
something similar in there.

I just checked the SDL 1.2.4 source, and I already do this in Windows:

void WIN_GL_GetProcAddress(_THIS, const char proc)
{
void *func;

/* This is to pick up extensions */
func = this->gl_data->wglGetProcAddress(proc);
if ( ! func ) {
    /* This is probably a normal GL function */
    func = GetProcAddress(this->gl_config.dll_handle, proc);
}
return func;

}

Were you talking about a different platform?

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

5

No, Win32 is the primary one which has this problem, but I would like you
to apply it to other platforms as well, just in case. After all,
glXGetProcAddress is not guaranteed to return normal functions either, and
if it’s available, dlsym may not know all symbol names of a function.

Granted, glXGetProcAddress is fairly new (it’s part of GLX 1.3) and it
would be foolishness for someone to depend on its use given that it’s
barely any older than OpenGL 1.3 by a number of months. However, you’ve
read my rants before - driver vendors, OS vendors, and everyone else for
that matter tend to do silly things with OpenGL drivers… It’d be best
to do as you’re doing for Win32 everywhere if you’re not. I just checked
and you don’t use it for X11.

If the above is not the problem we’re having with 3dfx and Win32, I’m not
sure what is. I’ll work on it some more. Sorry for the false alarm with
Win32 at least, I’ll check the code closer next time. =(

Speaking of OpenGL silliness, I just finished DynGL generation 3. It’s
much cleaner code now, and I’m looking for testers (especially who can
test Win32 or C++ with it!) I’ve still got to build a dglfuncs.h for the
common functions used by OpenGL tutorials (we don’t use 2/3 of those
functions in Project Twilight!), and document it all better. It consists
of a header (dyngl.h) which you use in place of SDL_opengl.h, a single
source file (dyngl.c) which contains the support functions and extensions
list processing, and the macro-abusing dglfuncs.h which has all of the
function macros in it.

If you’re remotely aware of how SDL handles OpenGL binding internally,
this works quite similarly, and in fact uses the SDL functions to work
anywhere it does… All of the OpenGL function pointers are named qglFoo
for each glFoo because Q2 and Q3A use these and the namespace has been
effectively filled for this purpose for life due to the popularity of the
Id Software, Inc games… As with SDL, there’s facility to disable a
function you’re not using to save four to eight bytes of RAM per function,
and in Twilight as I said we don’t use very many functions at all - so we
only have the ones we use in the file. Zeph’s also written a short perl
script to spit out the necessary macro given a function name.On Thu, May 16, 2002 at 08:43:04AM -0700, Sam Lantinga wrote:

Basically, if the normal allocation method fails, try to get the symbol
the hard way. If that fails, you’re screwed. Note, as I’ve done this
here, you will need to add GL_Handle to SDL_sysvideo.h - I didn’t see
something similar in there.

I just checked the SDL 1.2.4 source, and I already do this in Windows:

void WIN_GL_GetProcAddress(_THIS, const char proc)
{
void *func;

/* This is to pick up extensions */
func = this->gl_data->wglGetProcAddress(proc);
if ( ! func ) {
    /* This is probably a normal GL function */
    func = GetProcAddress(this->gl_config.dll_handle, proc);
}
return func;

}

Were you talking about a different platform?

–
Joseph Carter This end upside-down

If the user points the gun at his foot and pulls the trigger, it
is our job to ensure the bullet gets where it’s supposed to.

-------------- 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/20020516/2fa42002/attachment.pgp