While I was adding some new extensions to my program, I realized that some ARB functions have the ARB suffix (ie for geometry shader), whereas other ones don’t (ie framebuffer object ARB extension).
Any reasons for making such differencies ?
The ones without -ARB (or any other similar suffix; -EXT, -NV, etc) are not extensions. They’re part of the core API for a certain given GL_VERSION. Example: if GL_VERSION is 1.5 or higher, then vertex buffers are not an extension. That doesn’t mean that you get to avoid GetProcAddress (or equivalent) but it does mean that - assuming the driver writers have done their job - you can rely on them to be present and should generally use the versions without -ARB (or whatever).
An OpenGL driver isn’t actually obliged to export any extensions for functionality that’s part of the core API for it’s GL_VERSION. In practice this doesn’t happen, but in theory it could. So an OpenGL 3.3 driver may elect to not export the old GL_ARB_multitexture extension, for example, because multitexture is core in 3.3 and the driver doesn’t need the extension for it to work.
Your explanation is very clear, thanks for this.
So, doesn’t it mean it might be bad to use glext.h file providen on this website since the ARB/EXT… suffixes are not always happend to extensions ? Meaning that, for a given card, depending on the driver, the GL version can change, and for different cards, even more.
So, what GL version to hint when providing a glext.h header ?
Moreoever, when I’d like to get some function pointers for some extensions, which one should I check ? With ARB or without ARB extension.
For example: PFNGLISRENDERBUFFERPROC is declared on my new glext.h file on my laptop under Linux. But, maybe PFNGLISRENDERBUFFERARBPROC will be declared on another computer. And if I’d like to check this extension, I’ll get an PFNGLISRENDERBUFFERPROC “used without having been initialized” or so error from compiler.
Does it mean I should definately forget about glext.h ? (Thus linked with my previous topic).
What do you people here think about this ? For making answers more simple, I’d like to avoid using glew and so on. Do some people here create his own gl.h and glext.h headers ?
Thanks in advance.
While I was adding some new extensions to my program, I realized that some ARB functions have the ARB suffix (ie for geometry shader), whereas other ones don’t (ie framebuffer object ARB extension).
Yes. These are Core extensions.
ARB_framebuffer_object is functionally virtual identical to the equivalent feature provided by GL 3.0. So giving them different entrypoints and enumerators from the core 3.0 wouldn’t make sense.
Core extensions are a relatively new concept, introduced in the massive release of extensions started by GL 3.0. They promote forward compatibility, by allowing implementations that can’t fully implement 3.0 to implement parts of it. You can test for ARB_fbo or GL 3.0; if either is available, you can use the exact same functions and enumerators. You don’t have to have a different codepath for ARB_fbo or core 3.0.
I’d generally bite the bullet and just use GLEW - it makes life easier in more than one way.
If you’d still rather not then I’d suggest choosing a baseline GL_VERSION and coding to that. That means that for entrypoints for that GL_VERSION and below use the versions without -ARB, for entrypoints that don’t exist in that GL_VERSION use the versions with -ARB.
I wouldn’t bother with -EXT or vendor-specific versions unless you’ve got a very small target audience where you know exactly what the hardware is. The exception of course is well-known -EXT extensions (an example would be anisotropic filtering).
Thank you both, this is very clear.