Why 3D texture functions are missing?

I have a Geforce4 MX 440 . In the manual is written that the card has support for OpenGL 1.3 , but the GL_VERSION string returns me version 1.4. The 3d texturing requires an OpenGL 1.2 compatible card. So why are missing the 3d texturing related functions from my opengl32.dll? (I installed the latest drivers and I have Win2K).

I’m shure that the card has to support 3d texturing! The getinteger function returns me 64 as the maximum size for 3d textures,
and in the manual it is written that 64X64X64 is the max 3d texture size.

Peter //Mr.WereWolf//

You need to get the function pointer from the OpenGL extension mechanism under Windows. Windows’s opengl32.dll only exports the OpenGL 1.1 API and nothing more. Anything else needs to handled via extensions.

opengl32.dll is under Microsoft’s control, not individual IHVs, so there’s little NVidia, ATI or anyone else can do without MS’s support.

BTW: other programs using 3d texturing are crashing or giving an error!

I am not sure, but i think the GF4 MX does not support 3D textures. However i could be very wrong there…


Jan is absolutely right …

Thanks to NVidia marketing the GeForce4 MX is in fact a GeForce2.5. GeForce2 class hardware does not support 3D textures in hardware.


There are several things going on here:

  1. The Microsoft “default” bindings only cover 1.1. Thus, you get link errors if you try to blindly use higher functions, and you have to extract them using wglGetProcAddress(), after validating that the implementation does support the functions, by checking GL_VERSION, or glGetString() on the extensions string.

  2. The version that the GeForce4 MX exposes is one that supports 3D texturing. However, because the hardware doesn’t support it, the driver emulates this functionality in software. If you use it, it’ll be very slow.

  3. If you crash on 3D texturing, then it’s likely that some program is using the API incorrectly; i e it might be asking for some EXT or ARB function without checking for the appropriate extension string, and then calling the function with no error checking. It’s likely that the software implementation only exports the “pure” GL bindings, not the EXT/ARB decorated extension variants.