Loading compressed textures in Linux

[Stephen_Webb]

Hello again.

I am trying to load compressed textures into OpenGL on Linux. I have been able to load an uncompressed texture and successfully get the card/driver to compress it (I verified with glGetTexLevelParameteriv() calls…).

My problem is in using the glCompressedTexImage2DARB() and
glGetCompressedTexImageARB() functions.

When I compile, I get the following undefined symbol errors:

compressed_texture.cc:171: glGetCompressedTexImageARB' undeclared (first use this function) compressed_texture.cc:171: (Each undeclared identifier is reported only once for each function it appears in.) compressed_texture.cc:172: glCompressedTexImage2DARB’ undeclared (first use
this function)

Is this not supported with the Linux driver? Do you have any suggestions of how to make it behave?

Thanks

-Steve

[pkaler]

Functions are declared in a header. Usually glext.h or something.

Then functions are defined in a .so file.

The function you are looking for is not declared. You could update your glext.h yourself or use something like the extension loading library. http://www.levp.de/3d/index.html

It supports GL_ARB_texture_compression.

[Stephen_Webb]

What I found was that the function:

glGetCompressedTextureARB is declared in glext.h (which I am includin) inside of a #ifdef GL_GLEXT_PROTOTYPES block.

I grepped through all of the opengl headers, and couldn’t find anywhere where GL_GLEXT_PROTOTYPES was #defined. SO, I added a line in my main.cc file before any #includes…

#define GL_GLEXT_PROTOTYPES

now the program compiles and runs fine, but it just seems weird to me.

??

-Steve

[azcoder]

I had to do a similar thing to get GLX pbuffer support. As far as I know, declaring GL_GLXEXT_PROTOTYPES is the correct way to enable these functions.

Perhaps some of these functions are only “supported” for testing purposes in the driver?

Anyway, if it works then code on…

Good Luck

[imported_elias]

That’s probably because gl extension functions are meant to be loaded dynamically, in which case the glext.h prototypes would interfere with the functions pointer symbols with the same name.

• elias

[OneSadCookie]

You should never name your function pointers exactly as the entrypoints for precisely this reason – not all OpenGL headers let you avoid getting the prototypes the way your glext.h does.

The question here is what are you planning to do with this project? If it’s just for your own entertainment and/or edification, you can quite happily define GL_GLEXT_PROTOTYPES and forget about it. If you want to distribute a binary to someone who might have a different graphics card driver, you should use glXGetProcAddressARB to retrieve the function pointers (or let an extension-loading library do it for you).

[Stephen_Webb]

If you want to distribute a binary to someone who might have a different graphics card driver, you should use glXGetProcAddressARB to retrieve the function pointers (or let an extension-loading library do it for you).

Thanks for your insight. I will certainly keep this in mind and do it properly.

-Steve

[idr]

Also, when you use glXGetProcAddressARB do NOT name your function pointer the same thing as the function. That is, DO NOT do this:

glCompressedTexImage2DARB = glXGetProcAddressARB(“glCompressedTexImage2DARB”);

libGL is usually linked with “lazy” symbols, just like libc. If there is a call to glCompressedTexImage2DARB in libGL, it will call YOUR function pointer instead of its internal function. The net result is you will spend a lot of time trying to figure out why your app is segfaulting.