5

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

genpfault
  • 51,148
  • 11
  • 85
  • 139
Tim Orton
  • 329
  • 3
  • 14
  • 1
    Are you sure you have a current GL context when you call all that? – genpfault Apr 27 '11 at 20:35
  • I have #included , , and "glext.h" Is there something Ive missed out? – Tim Orton Apr 27 '11 at 20:40
  • Did you check the contents of glGetString(GL_EXTENSIONS)? It's the only reliable way to know what's supported and what's not. You should also check glGetString(GL_RENDERER) and glGetString(GL_VENDOR). It may very well be, that your program falls into software rasterizer mode. – datenwolf Apr 27 '11 at 21:14
  • They all return a bad pointer - expression cannot be evaluated. I dont know what software rasteriser mode is... – Tim Orton Apr 27 '11 at 22:47
  • @Tim: Windows falls back into software emulation if you request an OpenGL context configuration that's not supported by (the) hardware driver. For example enabling accum buffer or BITMAP rendering. However glGetString should not return invalid pointers, unless you don't have a valid render context active. – datenwolf Apr 28 '11 at 15:07
  • @datenwolf: Thanks, I have a render context and I have looked at the contents of GL_EXTENSIONS. What is it that I'm looking for? I can see things like GL_ARB_multitexture in there. GL_RENDERER tells me ATI Radeon HD 5700 series GL_VENDOR says ATI Technologies Inc. – Tim Orton Apr 28 '11 at 16:36
  • @Tim: What you were looking for was GL_ARB_multitexture. However I now noticed something. See my answer (don't know if that really is your problem, though). – datenwolf Apr 29 '11 at 06:47

4 Answers4

1

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.

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • Should it matter that my render context is in my main.cpp, which calls the initialiser for the object using multitexturing? I cant seem to get GLuint textures to work either? I am including all the right files, but is there any reason that wglGetProcAddress, glGenTextures and glBindTexture would all fail like this? – Tim Orton Apr 29 '11 at 11:11
  • 1
    The only reason for glGenTextures to fail is, that there is no valid render context made current at the time of calling glGenTextures. Are you use multiple threads? If so, take note that a render context can be active in only one thread at a time. You can switch the thread by first releasing the context in the one thread, then making it current in the other. – datenwolf Apr 29 '11 at 11:21
  • No, I'm not multithreading. The only thing I can think of is the way I've set it up, It's my first implementation of the MVC. I initialise the render context in my main, first. Then I create the objects. The GL code is in the View layer of the MVC. The render context can't have scoped out could it. If you think I am initialising the render context incorrectly, could you show me a website that will show me how? – Tim Orton Apr 29 '11 at 11:58
  • @datenwolf: Ok, I think I see the problem; I'm initializing the objects before the main() method where I create a rendering context. I am initializing it outside of the main() method so that they can be seen by other methods - render(), idle() etc... How can I arrange it so that the render context is called first? – Tim Orton Apr 29 '11 at 16:31
  • @Tim: Sounds like you're using global instances of some class; then you'll of course end up with static construction. The solution: Don't use static construction. Instead in your classes have some function *init* or attach to context, something like that. Of course in a properly written OOP wrapper you'd manage the GL context as a separate class. The context class would manage a singleton that keeps a list of all contexts the program holds. Then classes for OpenGL objects (textures, FBOs, VBOs), but not instanciable by construction, but generatable from the contex (think shared contexts). – datenwolf Apr 29 '11 at 17:32
  • @datenwolf: Thanks for all your help, but I'm not sure I understand. Where Do I put this? PlayerModel playerM; IPlayerModel *playerMI = &playerM; PlayerView playerV(playerMI); IPlayerView *playerVI = &playerV PlayerController playerC(playerMI, playerVI); ... and where do i make the render context? – Tim Orton Apr 29 '11 at 17:50
  • 1
    The rendercontext is either created by you (wglCreateContext, wglMakeContextCurrent), or a library you use. GLUT creates the render context in glutCreateWindow, SDL in SDL_SetVideoMode etc. All the stuff that requires a context must be done after it has been created. You classes, without knowing how they works it's hard to say, where and how to place them. Please provide at least an exhaustive example. – datenwolf Apr 29 '11 at 18:01
  • @datenwolf: Thanks datenwolf. I've got it working now, you've been a great help :) – Tim Orton Apr 30 '11 at 01:28
1

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.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
0

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.

Vladivarius
  • 498
  • 1
  • 3
  • 14
0

I recommend GLEW/GLEE for extension management.

genpfault
  • 51,148
  • 11
  • 85
  • 139
  • 1
    It isn't guaranteed to. On systems like Windows, where the system opengl lib only has entry points for the basic 1.2 functions, you have to load all other function pointers by yourself. – yuriks Apr 27 '11 at 22:55
  • ...and GLEW/GLEE take care of all that for you :) – genpfault Apr 27 '11 at 22:57
  • ive just tried using glee but it didnt seem to work. do i have to initialise glMultiTexCoord2fARB and glActiveTexture? – Tim Orton Apr 27 '11 at 23:05