Understanding the OpenGL Extension Handler

[jmpep]

I'm trying to understand the internals of the OpenGL Extension Handler, but I'm having difficulties (probably due to my total lack of experience with OpenGL)

In the header file, there are a lot of helper functions. For example:

Code: Select all

inline void COpenGLES1ExtensionHandler::extGlBindProgram(GLenum target, GLuint program)
{
#ifdef _IRR_OPENGL_USE_EXTPOINTER_
	if (pGlBindProgramARB)
		pGlBindProgramARB(target, program);
#elif defined(GL_ARB_vertex_program)
	glBindProgramARB(target, program);
#else
	os::Printer::log("glBindProgram not supported", ELL_ERROR);
#endif
}

If the _IRR_OPENGL_USE_EXTPOINTER_ macro is defined, a pointer to the OpenGL extension is used. The problem I see is that the pointer could only be defined if GL_ARB_vertex_program = 1, which is not checked.

Also, I've read who-knows-where that using external pointers is only needed when no support for the extension is available in the platform's gl.h file. Providing that, I cannot understand why anytime _IRR_OPENGL_USE_EXTPOINTER_ is defined, the usage of external pointers is preferred over using the actual function of the extension.

[hybrid]

No, the pointer is defined if the header file glext.h is recent enough. And we have the latest available in Irrlicht (at least in SVN/trunk). So the pointer exists, but can be 0 if the extension is not available. Hence, it's checked each time.
Yes, if your OpenGL version supports the extension as an official ARB part it can be accessed without the pointer. However, your app would only work on machines with at least that OpenGL version, but would not become noticeably faster. Hence, we buy major flexibility for minor speed impact.
You can change the IrrCompileConfig, though, and disable the OPENGL_USE_EXTPOINTER define. Then, you can only use those features which are provided by your gl.h.

[jmpep]

The problem is that the gl.h can define a macro of an extension without defining its pointer if the macro is supported in the platform's lib. Afterwards, glext.h will not define the pointer neither, as it first checks the macro of the extension and, as it is defined, glext.h does not do anything else. This can lead to problems -or at least, for a n00b like me, a lot of headaches.

It is the case with the gl.h of the PowerVR OpenGL|ES SDK. It defines GL_OES_point_sprite -for example- but it does not define its pointer type. I'll see how to deal with this.

Anyway, I understand now why Irrlicht does what it does, so thanks you very much

[hybrid]

The ogl-es driver does handle this stuff differently. However, also ogl-es does use extensions. So it's just a matter of usage to reenable the extension mechanism.