Another Ext. Question (if you don't mind) This time PointParameter

I have a supposedly OpenGL 1.5 compliant video card, yet when it comes to loading the functions for the GL_ARB_point_parameters extension, the float versions load fine, but the 1.4 Standard explicitly states in Section 3.3 that equivalent integer versions should be available as well. The integer versions, well, aren’t there… What do you do in cases like this? I mean, I’d like my program to minimally target at least OpenGL 1.5, and I’d like to use every function without worrying about and having to check all the time whether or not a function that should be there, isn’t! Man, I’m beginning to hate testing older cards! lol.

Are you sure you used the correct names?

GL_ARB_point_parameters added only
glPointParameterfARB and glPointParameterfvARB

The core contains glPointParameteri, glPointParameterf, glPointParameteriv, glPointParameterfv (no ARB suffixes!)

I’d be curious which old cards don’t implement this correctly?

Oh, I think I see now. So you mean that since the ARB extension only has the f and fv versions, a card that from NVIDIA which says “a professional and complete OpenGL 1.5 implementation” only has to implement what’s in that extension and not neccessarily what’s in the core? The two cards that are giving me trouble are a GeForce MX 4000 (1.5) and a GeForce MX 4 400 (1.3, though this one returns a 1.5.5 version string for some reason).

Thanks,
Josh

No it hasn’t to only implement what’s in the extension. The core functions should also be implemented, and they are. The only difference is that you don’t need to get the addresses of the core functions since they are enable by default. Only check those functions with EXT and ARB suffixes (and so on: NV, ATI, SGI…).

Oh wow, thanks you guys, I’m really getting the hang of this now.

// GL_ARB_point_parameters
wglGetProcAddress(“glPointParameterfARB”); // works as expected
wglGetProcAddress(“glPointParameterfvARB”); // works as expected
wglGetProcAddress(“glPointParameteriARB”); // fails, not part of extension!
wglGetProcAddress(“glPointParameterivARB”); // fails, not part of extension!
wglGetProcAddress(“glPointParameteri”); // works, part of core!
wglGetProcAddress(“glPointParameteriv”); // works, part of core!

so glPointParameteri and glPointParameteriv have been implemented :smiley: .
Is it like this for all cards?

Correct, the function names glPointParameteriARB and glPointParameterivARB never existed.

You need to take the function names in the core spec literally.

>>Is it like this for all cards? <<

It should be like this for all boards and all extensions.

>>The only difference is that you don’t need to get the addresses of the core functions since they are enable by default.<<

Wrong. OpenGL under Windows needs to get all functions above OpenGL version 1.1, because Microsoft’s OpenGL32.dll doesn’t contain entry points beyond version 1.1.

I’m not sure why you’re doing this, but an extension checker has been done before:
http://www.realtech-vr.com/glview/index.html

Oh wow, thanks for that link Relic. That’s really going to help out. I was just going through all the different OpenGL functions, learning what they’re used for, forcing myself to read the standard, and killing time writing my own little extension library rather than using something like GLEE or whatever.

I also noticed this earlier too…
GL_ARB_occlusion_query was not found, but has the entry point glBeginQueryARB
GL_ARB_occlusion_query was not found, but has the entry point glDeleteQueriesARB
GL_ARB_occlusion_query was not found, but has the entry point glEndQueryARB
GL_ARB_occlusion_query was not found, but has the entry point glGenQueriesARB
GL_ARB_occlusion_query was not found, but has the entry point glGetQueryObjectivARB
GL_ARB_occlusion_query was not found, but has the entry point glGetQueryObjectuivARB
GL_ARB_occlusion_query was not found, but has the entry point glGetQueryivARB
GL_ARB_occlusion_query was not found, but has the entry point glIsQueryARB

Is this another case like multisampling where the vendor chose to hide the extension from the extension string because it isn’t hardware accelerated?

Thanks again,
Josh

If the extension string isn’t present, then the extension isn’t officially supported. If you can still get the function pointers you should be very careful, becuase what you get could be garbage, or some test implementation that is not working properly, or anything not behaving as it should.

The only rule is; if the extension string is present, then so are the functions. There are no rules saying that if the string isn’t there, then the functions shouldn’t be there either.

The proper way to check if you can use an extension is to see of the extension string is present. The function pointers may not tell you the true story.

Cool, thanks for clarifying!
Josh

Cool, thanks for clarifying!
Josh