Linux opengl extension

SDL Development
1

ive been trying for a couple of weeks to get access to ALL opengl
extensions with SDL (with mixed results),
some word eg multitexture but some dont eg secondarycolor.
or pointparametersEXT works but pointparametersARB doesnt.

does anyone have any idea what could possibly be happening?
i would appreciate if an expert would mail me with help (so i can
describe fully whats NOT happening)

zed–
lets hear it for billy bollux and his bouncing balls
http://uk.geocities.com/sloppyturds/kea/kea.html

2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Saturday 04 January 2003 05:38, zed wrote:

ive been trying for a couple of weeks to get access to ALL opengl
extensions with SDL (with mixed results),
some word eg multitexture but some dont eg secondarycolor.
or pointparametersEXT works but pointparametersARB doesnt.

does anyone have any idea what could possibly be happening?
i would appreciate if an expert would mail me with help (so i can
describe fully whats NOT happening)

It would be helpful if you told us why/how it “doesn’t work”.

Are you sure the extensions actually exist? Check the GL_EXTENSIONS string
for that. A driver will only provide pointparametersEXT but not
pointparametersARB if it was written before pointparameters was promoted to
an ARB extension, for example.

Do you use SDL_GL_GetProcAddress() to get the extension functions?

cu,
Nicolai
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+FuWHsxPozBga0lwRAnsYAKDg+pBpcCCCEJLnQfP4UgLj0oJ9rwCdEmDw
5xdypjRj2yDtFlGkwKLjmNc=
=m49s
-----END PGP SIGNATURE-----

3

Nicolai Haehnle wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ive been trying for a couple of weeks to get access to ALL opengl
extensions with SDL (with mixed results),
some word eg multitexture but some dont eg secondarycolor.
or pointparametersEXT works but pointparametersARB doesnt.

does anyone have any idea what could possibly be happening?
i would appreciate if an expert would mail me with help (so i can
describe fully whats NOT happening)

It would be helpful if you told us why/how it “doesn’t work”.

Are you sure the extensions actually exist? Check the GL_EXTENSIONS string
for that. A driver will only provide pointparametersEXT but not
pointparametersARB if it was written before pointparameters was promoted to
an ARB extension, for example.

Do you use SDL_GL_GetProcAddress() to get the extension functions?

yes to everything (note it works under windows)
heres another message i started about it.
http://www.opengl.org/discussion_boards/ubb/Forum4/HTML/000830.html

from an email from a nvidia developer> On Saturday 04 January 2003 05:38, zed wrote:

One of our developers changed the behavior of the driver to avoid the
dynamic symbol resolution we are currently doing, but found that it didn’t
actually fix your test.

What he found was that libsdl doesn’t actually use the
GLX_ARB_get_proc_address extension. Instead, it simply calls dlsym().
First it tries “glFunctionARB”; then it tries “_glFunctionARB” if it fails.
I don’t know how Linux symbol naming works, but there seems to be something
weird going on. dlsym has a flag RTLD_GLOBAL that makes symbols “global” so
they are returned even if they aren’t in the named executable – not sure if
symbols in your main executable would be global or not. If they are,
perhaps they will be returned by any dlsym() call? In any event, there may
be multiple symbols of any given name here.

hes refering to this

void X11_GL_GetProcAddress(_THIS, const char proc)
{
static char procname[1024];
void* handle;
void* retval;

     handle = this->gl_config.dll_handle;

#if 0 /* This doesn’t work correctly yet */
if ( this->gl_data->glXGetProcAddress ) {
…
…

also so why isnt this workinh yet #if 0 /* This doesn’t work correctly
yet */

–
lets hear it for billy bollux and his bouncing balls
http://uk.geocities.com/sloppyturds/kea/kea.html

4

from an email from a nvidia developer

One of our developers changed the behavior of the driver to avoid the
dynamic symbol resolution we are currently doing, but found that it didn’t
actually fix your test.

What he found was that libsdl doesn’t actually use the
GLX_ARB_get_proc_address extension. Instead, it simply calls dlsym().
First it tries “glFunctionARB”; then it tries “_glFunctionARB” if it fails.
I don’t know how Linux symbol naming works, but there seems to be something
weird going on. dlsym has a flag RTLD_GLOBAL that makes symbols “global” so
they are returned even if they aren’t in the named executable – not sure if
symbols in your main executable would be global or not. If they are,
perhaps they will be returned by any dlsym() call? In any event, there may
be multiple symbols of any given name here.

hes refering to this

void X11_GL_GetProcAddress(_THIS, const char proc)
{
static char procname[1024];
void* handle;
void* retval;

     handle = this->gl_config.dll_handle;

#if 0 /* This doesn’t work correctly yet */
if ( this->gl_data->glXGetProcAddress ) {
…
…

also so why isnt this workinh yet #if 0 /* This doesn’t work correctly
yet */

Thanks for the info. The old Mesa Voodoo drivers would actually crash if
you called glxGetProcAddress on some extensions. It’s probably save to enable
that code now, so try it and see if that fixes your problem.

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