‘glCompressedTexImage2DARB’ was not declared in this scope
Lose the ARB bit.
--
John Tsiombikas (Nuclear / Mindlapse)
http://nuclear.sdf-eu.org/
#ifdef GL_GLEXT_PROTOTYPES
#include <GL/glext.h>
void example()
{
glCompressedTexImage2D(...);
}
In Windows you can't use the PROTOTYPES, you have to use the typedef's
and wglGetProcAddress().. but in Linux.. it's piece of cake. =)
glCompressedTexImage2D is OpenGL 1.3
glCompressedTexImage2DARB is "GL_ARB_texture_compression" extension
glCompressedTextureImage2DEXT is "GL_EXT_direct_state_access"
extension
For the first, non-ARB function you just need to check that your
OpenGL implementation is at least 1.3, for the other two you need to
check the extension string. The EXT is "worst" of the lot, so I would
recommend looking for the functions in order I listed them above.
It depends if you have "glext.h" header installed or not, you can
download the latest one from Khronos.org or from your package manager
in your distro. There are different kinds of drivers and distros so
these are just rules-of-thumb.
In general, the "glext.h" is a really neat header to use as quick and
dirty reference. =)
#define GL_GLEXT_PROTOTYPES
#include <GL/glext.h>
copy'n'paste error; less typos when copy and paste but forgot to edit
the macro. =)
Try upgrading your glext.h, check the glext.h you use now for
glGenBuffersARB, check your OGL version (glGenBuffers is 1.5 if I
don't remember wrong), check for the extension for glGenBuffersARB in
your driver's extension string..
If you have the extension but the driver won't have the prototype then
you have to querry it and use the typedef from later header.
The next function you won't find, you know the drill:
- check OGL version, then you know if the function is supported in the
driver
- if version is too small or there is no version with specific
function in it yet, check the extension string for different versions
of the extension (EXT, ARB, ???)
- the driver may or may not support the prototype and linking the easy
way, if not, then link dynamically with "get proc address" -approach.
There are libraries which make this process more convenient for you,
google for GLEE; GLEW, glext++ and others. But it's good to know how
this stuff works. It's basically three components:
- OGL library
- OGL driver
- gl.h, glext.h, etc. ("the headers")
In a good distribution (Linux) these are matching versions.. but ppl
upgrade their drivers manually, for example, I use VMWare to compile
and test my code in different distros and 32 bit, 64 bit, etc. and see
many kinds of stuff. For example, the "main" OS for me is 32 bit
Ubuntu. I use NV gfx card. The Ubuntu's drivers are obsolete for my
tastes, I also program OpenCL, so I download the NV drivers from
nvidia.com and in that situation the libraries and headers that come
with Ubuntu are OUT OF DATE!! So, I get the latest glext.h from
Khronos, but they don't distribute the OGL libraries to link with so I
am linking with whatever comes with Ubuntu (I don't bother upgrading
those "manually", so, to use the latest extensions I will have to
"getproc" some of the API functions.
Sounds messy? It's not, really, it's just very flexible and when I
know how it works it's easy. I just have abstraction code to deal with
that, at the other wide of the abstraction, I just check if a feature
is available and use it. No hassle. That's where these libraries I
recommended google search for come into the picture (I maintain my
own, which is written in easy-to-upgrade way I haven't seen other
libraries to use but that's their loss =)
Good luck!??!
michael@23-194-pool:~> glewinfo | grep glGenBuffer
glGenBuffers: OK
glGenBuffersARB: OK
michael@2-194-pool:~>
The problem might be unrelated, something like this:
namespace foo {
#include <GL/glext.h>
// oops
Or something completely different. It should work if nothing "special"
like above example isn't breaking anything.