CODEWITHSUNDEEP
c++openglmultitexturing
Tim Orton
Tim Orton

Reputation: 338

OpenGL Multitexturing - glActiveTexture is NULL

I have started a new project, which I want to use multitexturing in. I have done multixexturing before, and is supported by my version of OpenGL

In the header I have:

GLuint  m_TerrainTexture[3];//heightmap, texture map and detail map
GLuint  m_SkyboxTexture[5]; //left, front, right, back and top textures

PFNGLMULTITEXCOORD2FARBPROC glMultiTexCoord2fARB;
PFNGLACTIVETEXTUREARBPROC   glActiveTexture;

In the constructor I have:

glActiveTexture = (PFNGLACTIVETEXTUREARBPROC) wglGetProcAddress((LPCSTR)"glActiveTextureARB");
glMultiTexCoord2fARB = (PFNGLMULTITEXCOORD2FARBPROC) wglGetProcAddress((LPCSTR)"glMultiTexCoord2fARB");

if(!glActiveTexture || !glMultiTexCoord2fARB)
{
    MessageBox(NULL, "multitexturing failed", "OGL_D3D Error", MB_OK);
}

glActiveTexture( GL_TEXTURE0_ARB );
...

This shows the message box "multitexturing failed" and the contents of glActiveTexture is 0x00000000

when it gets to glActiveTexture( GL_TEXTURE0_ARB ); I get an access violation error

I am implementing the MVC diagram, so this is all in my terrain view class

Upvotes: 5

Views: 4663

Answers (4)

Vladivarius
Vladivarius

Reputation: 518

Rastertek tutorial has the complete setup required to make wglGetProcAddress to work. GLEW doesn't work for me either, I've tried everything I could think of and I asked many people about it but it simply doesn't work in VS 2012, not to mention the enormous frustration I experienced when I wanted to compile a shader.

Upvotes: 0

Nicol Bolas
Nicol Bolas

Reputation: 473437

GLEE is a dead library; it hasn't been updated in a long time.

GLEW is a fine extension loading library, but it has some issues working with core 3.2 and above.

I would suggest GL3W. The beauty of it is that it is self-updating; it downloads and parses the headers by itself. The downside is that you need a Python 2.6 installation to generate the loader. But it provides reasonably good results otherwise.

Upvotes: 1

datenwolf
datenwolf

Reputation: 162164

You quoted your code to load the extensions like following:

PFNGLMULTITEXCOORD2FARBPROC glMultiTexCoord2fARB;
PFNGLACTIVETEXTUREARBPROC   glActiveTexture;

glActiveTexture = (PFNGLACTIVETEXTUREARBPROC) wglGetProcAddress((LPCSTR)"glActiveTextureARB");
glMultiTexCoord2fARB = (PFNGLMULTITEXCOORD2FARBPROC) wglGetProcAddress((LPCSTR)"glMultiTexCoord2fARB");

This is very problematic, since it possibly redefines already existing symbols. The (dynamic) linker will eventually trip over this. For example it might happen that the assignment to the pointer variable glActiveTexture goes into some place, but whenever a function of the same name is called it calls something linked in from somewhere else.

In C you usually use a combination of preprocessor macros and custom prefix to avoid this problem, without having to adjust large portions of code.

PFNGLMULTITEXCOORD2FARBPROC myglMultiTexCoord2fARB;
#define glMultiTexCoord2fARB myglMultiTexCoord2fARB

PFNGLACTIVETEXTUREARBPROC   myglActiveTexture;
#define glActiveTexture myglActiveTexture

glActiveTexture = (PFNGLACTIVETEXTUREARBPROC) wglGetProcAddress((LPCSTR)"glActiveTextureARB");
glMultiTexCoord2fARB = (PFNGLMULTITEXCOORD2FARBPROC) wglGetProcAddress((LPCSTR)"glMultiTexCoord2fARB");

I really don't know of any other reason why things should fail if you have a valid render context active and the extensions supported.

Upvotes: 1

genpfault
genpfault

Reputation: 52083

I recommend GLEW/GLEE for extension management.

Upvotes: 0

Related Questions