Game Development Reference
In-Depth Information
How to do it…
1.
In the previous recipe, we mentioned the
sLGLAPI
struct. It contains pointers
to OpenGL functions that we load at startup dynamically. The declaration can
be found in
LGLAPI.h
, and it starts like in the following code:
struct sLGLAPI
{
sLGLAPI() { memset( this, 0, sizeof( *this ) ); };
…Win32 defines skipped here…
PFNGLACTIVETEXTUREPROC glActiveTexture;
PFNGLATTACHSHADERPROC glAttachShader;
PFNGLBINDATTRIBLOCATIONPROC glBindAttribLocation;
…
2. A variable is deined to hold a pointer to this structure:
sLGLAPI* LGL3;
3.
This means we have to call all OpenGL functions through pointers contained in
LGL3
.
For example, following is the code for
OnDrawFrame()
from the
2_OpenGLES2
example:
void OnDrawFrame()
{
LGL3->glClearColor( 1.0, 0.0, 0.0, 0.0 );
LGL3->glClear( GL_COLOR_BUFFER_BIT );
}
A bit more complicated than a simple
glClear(GL_COLOR_BUFFER_BIT)
call,
so why would we need it? Depending on how your application links to OpenGL on
different platforms,
glClear
-like entities can be represented in two ways. If your
application is linked dynamically to OpenGL, global symbols such as
glClear
are represented by global variables that hold pointers to functions retrieved from
a .
DLL/.so
library. Your application might also be statically linked against some
OpenGL wrapper library, exactly how it is done on Android with the
-lGLESv2
and
-lGLESv3
switches in
LOCAL_LDLIBS
. In this case,
glClear()
will be a function,
not a variable, and you will not be able to change the code it contains. Furthermore,
things get more complicated if we look at certain OpenGL 3 functions, for example,
glClearDepth(double Depth)
, only to ind out that OpenGL ES 2 has no direct
equivalent for them. That is why we need a collection of pointers to OpenGL functions
we can change at will.
