Ugly mess with EXT, v1.2 and opengl32.lib

OK. When developing in windows i need both the
opengl32.dll
opengl32.lib

in addition to a gl.h file conforming with the runtime library (dll,lib), right?. (btw: why doesn’t any develop-tools like MSVC++, BCBuilder etc. provide the v1.2 gl.h?)

Anyway… i intended to use the 3D texture extension, and included the glext.h. But still, i can not use the EXT functions because they aren’t in the DLL (and thus not in my LIB file (checked with implib and impdef). Compiling is OK, but it goes face down on linking… Is the DLL file adapted to my hardware on OS install? (have WinXP).(does this mean my card doesn’t support 3Dtexturing?)

Appreciate comments on this. It’s seems a bit blurry to me right now…

Until MS updates the openGL.dll/lib you have to either use the lib that was mentioned on the front page of this site, or do your own as in :

PFNGLMULTITEXCOORD2FARBPROC glMultiTexCoord2fARB = 0;
glMultiTexCoord2fARB = (PFNGLMULTITEXCOORD2FARBPROC) wglGetProcAddress(“glMultiTexCoord2fARB”);

and so on…

You do not mention which vid card you have, but only Radeon 8500, GF3 and GF4 support 3d textures.

Originally posted by Elixer:
[b]Until MS updates the openGL.dll/lib you have to either use the lib that was mentioned on the front page of this site, or do your own as in :

PFNGLMULTITEXCOORD2FARBPROC glMultiTexCoord2fARB = 0;
glMultiTexCoord2fARB = (PFNGLMULTITEXCOORD2FARBPROC) wglGetProcAddress(“glMultiTexCoord2fARB”);

and so on…

You do not mention which vid card you have, but only Radeon 8500, GF3 and GF4 support 3d textures.[/b]

Thanks for the info, i guess my card doesn’t support the 3DTexture (have a GF2MX) so it wouldn’t work.

When i use the wglGetProcAddress i get a valid pointer/entry point for the dll without using the opengl32.lib right?, but then i’m dependent of the function actually reside in the opengl32.dll or? Or am i bypassing the opengl.lib/dll alltogether and accessing the nv4_disp.dll directly?..

I didnt get a pointer to glTexImage3DEXT() with the wglGetProvAddress… I assumed that was just because the function was missing in the opengl32.dll (which it is). But if i’m bypassing the dll… hmm

am i totally out of the thinkingtrack now?? I will try everything with a GF3 card later…

Usually, you check if the hardware supports the function(glgetstring…). If not, it would be either emulated in software (slow!) or return back error.

openGL32.dll has all the software emulation routines (up to 1.1 I think, and the various other windows needed stuff). So when you use wglGetProcAddress(), it will either return a valid pointer, or not…

GF has 3D textures, since it implements opengl 1.2 and 1.3 and 3D textures are part of 1.2. The driver does not export EXT_texture3D because they are only software-emulated (slow)

NVIDIA driver has simulation routines for all(AFAIK) 1.2 and 1.3 functionality that isn’t supported in hardware. so if the version string is 1.2 or 1.3 you can get a valid pointer to glTexImage3D, but it will be emulated and very slow for this reason. (Speaking of GF class cards)

The lib mentioned on the front site a few days ago(I wrote it) does exactly the same you would do: it calls wglGetProcAddress for every function that should be present regarding to GL_EXTENSION and GL_VERSION strings. Its just much dirty work to write all the declarations and all the wglGetProcAddress calls

-Lev

Went into your site Lev and will try the lib extgl. Good initiative! It didn’t include the GL_EXT_texture3D though?

I’m using BC++Builder som i will have to compile a lib myself right?

But: I’m a bit confused with the functionpointer returned. Where do the pointer points? To the OPENGL32.DLL or to eg. Nvidias (in my case) display DLL’s (which then will perform it by hardware.)

opengl32.dll are only software emulation then?

By this i assume that if the function is not supported by hardware, and neither reside software-emulated in opengl32.DLL, i will not get a valid pointer.

The latter is where i think my case is at… Anybody can clear this for me please?

Originally posted by MainMic:
[b]Went into your site Lev and will try the lib extgl. Good initiative! It didn’t include the GL_EXT_texture3D though?

I’m using BC++Builder som i will have to compile a lib myself right?

But: I’m a bit confused with the functionpointer returned. Where do the pointer points? To the OPENGL32.DLL or to eg. Nvidias (in my case) display DLL’s (which then will perform it by hardware.)

opengl32.dll are only software emulation then?

By this i assume that if the function is not supported by hardware, and neither reside software-emulated in opengl32.DLL, i will not get a valid pointer.

The latter is where i think my case is at… Anybody can clear this for me please?[/b]

EXT_texture3D is not included, because it’s opengl 1.2 fuctionality and both NVIDIA and ATI have 1.2+ drivers.

You have either to compile it yourself, or include extgl.c in your project (as you can read on the site . I didn’t test is it with builder, please contact me if you have any problems compiling it.

To the whole pointer story: I don’t understand your problems: if the functionalily is supported by the driver you’ll get a valid pointer, if not - you won’t get a valid pointer, that easy. If you like to know about MS ICD mechanism try here:
http://www.google.com/search?q=opengl+icd+mechanism

-Lev