View Full Version : Loading compressed textures in Linux...
10-03-2003, 12:33 PM
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
When I compile, I get the following undefined symbol errors:
compressed_texture.cc:171: `glGetCompressedTexImageARB' undeclared (first use
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
Is this not supported with the Linux driver? Do you have any suggestions of how to make it behave?
10-03-2003, 02:06 PM
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.
10-03-2003, 02:38 PM
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..
now the program compiles and runs fine, but it just seems weird to me.
10-04-2003, 06:19 AM
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....
10-07-2003, 10:12 AM
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.
10-08-2003, 02:48 AM
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).
10-19-2003, 03:40 PM
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.
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.
Powered by vBulletin® Version 4.2.3 Copyright © 2017 vBulletin Solutions, Inc. All rights reserved.