crash with fog extension

hello people.

i wish to use the GL_EXT_fog_coord to custom fog a terrain (look at “problems with radial fog” topic, if interested)

the code to extend opengl for fog vertex array:



the setup/access code:

struct Tdmygridpoint {
Tdmyvert3f vert;
Tdmyrgb3f color;
Tdmytex2f tex;
float fogz;

Tdmygridpoint grid[64*64]; // something equivalent

// enable other arrays

// specify other arrays access point

rendering is done with calls to glArrayElement().

but when opengl access to the fog array the application crashes.
i’ve tested various approaches, but it still crash and i don’t know why… i’m about to step through the LIB-ICD code, but i’d like to avoid it

note that the function exist, and the compiler builds a correct call to it.

since the way i extended opengl is the same as into a nvidia example for multitexturing, i don’t think the problem is there…

card is a geforce ddr.

i’m going to download new drivers (if i find them and test them…

in the meantime, does any of you had experiences with fog vertex array exts?

thank you,


Are you sure that glFogCoordPointerEXT is actually getting a correct value? wglGetProcAddress maybe fails to load and return NULL. Then you trying to call glFogCoordPointerEXT when it’s pointing nowhere (well, NULL actually)?

You said “note that the function exist, and the compiler builds a correct call to it”. Yes, the compiler can make a correct call out of it, but you have to load the function before using it. glFogCoordPointerEXT is nothing more that a pointer to a function, so the compiler can’t assign a value to it when compiling.


I am not sure but you should try passing “glFogCoordPointerEXT” instead of “glFogCoordPointer” to the wglGetProcAddress…

I am using compiled vertex arrays and my calls are :
glLockArraysEXT=(XPFNGLLOCKARRAYSEXTPROC) wglGetProcAddress(“glLockArraysEXT”);
glUnlockArraysEXT=(XPFNGLUNLOCKARRAYSEXTPROC) wglGetProcAddress(“glUnlockArraysEXT”);

And it works…


P.S. : I am really not sure about that but it’s worth a try…

yes, i am sure about the presence of the function: wgl returns the correct address, and i assign it correctly to the function pointer.
with “the compiler builds…” i would meant this…
also, i’ve checked many times the update glext.h header i use, and it agrees the extension specs.
“…load the function”: i agree, and if loading is achieved with just a call to wglGetProcAddress(), then it’s all right up to now, and i have to check other things.

yes, i missed the EXT in this post.
in my sources it is there, and i’ve also tested if without the EXT opengl will return the same value: without EXT it returns NULL.

stepping through lib-icd code i see that the exception is invoked at “mov [edx],al” when edx==0…
this makes me think about NULL pointers…
maybe i’ve passed a NULL pointer somewhere…?
no, everything is right.

excuse me for those typos… keep on help !


ok, i’ve fixed it.
it was not some error of mine, it was due to the drivers… the new 3.68 detonator drivers fix this problem.

…well, almost.

the specs for EXT_fog_coord extension prototype the vertex array function like this:

void FogCoordPointerEXT(enum type, sizei stride, void *pointer)

that will end up into the extension header like this:

typedef void (APIENTRY * PFNGLFOGCOORDPOINTEREXTPROC) (GLenum type, GLsizei stride, const GLvoid *pointer);

now, i must suppose that nvidia done something wrong, since if i call the function with this prototype, the application crashes !!

i had to re-prototype it to:

void FogCoordPointerEXT(int size, enum type, sizei stride, void *pointer)


typedef void (APIENTRY * PFNGLFOGCOORDPOINTEREXTPROC) (GLint size, GLenum type, GLsizei stride, const GLvoid *pointer);

and set the size parameter always to 1.
that’s not a big problem…

but who is right? nvidia or the specs?
who i have to listen to?


[This message has been edited by dmy (edited 04-01-2000).]

[This message has been edited by dmy (edited 04-01-2000).]