Ugly Core Profile Creation

I’m trying to create a core profile context as described in the OpenGL Superbible text, creating a temporary context to get the extension functions and then use them to create another context. However using the gDebugger, it’s reporting this error:

Detected error: The debugged process asked for an extension function pointer (glXXXXXXXXXX) from one render context, but called this function pointer in another render context…

Something gDebugger does not like? or is it forbidden to do so?

Thanks.

What gDEBugger reported is quite correct. You should grab pointers using temporary context only for needed functions to create a new context. All other pointers should be grabbed from the new context.
Generally it is not a problem, but if you want to avoid gDEBugger’s message follow the previous advice. :wink:

Thanks Aleksandar. But you see the problem is more related to the way OpenGL contexts are created. It’s hacked into an ancient wgl functions that will never change.

You have three choices:

1: Use many of the various toolkits to abstract this stuff away.

2: Deal with it as Aleksandar suggested.

3: Use Direct3D.

Complaining about it isn’t going to solve the problem.

1: Use many of the various toolkits to abstract this stuff away.

These libraries and toolkits use the same ancient wgl calls, so the problem is there.

2: Deal with it as Aleksandar suggested.

It’s just a workaround/hack, but for how long are we going to deal with it.

3: Use Direct3D.

Maybe for games; not suitable for CAD applications.

Complaining about it isn’t going to solve the problem.

The whole idea of complaining is to show that we are not happy with the current way of handling context creation. The OpenGL API has improved and developed a lot, but the platform-specific part of it still dead. I know it’s up to the platform creators to change this but, if they don’t have any specification to follow, why should they bother?
It’s absolutely the ARB responsibility to make a specification for every aspect of OpenGL.

These libraries and toolkits use the same ancient wgl calls, so the problem is there.

No it isn’t. The problem, as you stated it, was “using the gDebugger, it’s reporting this error:”. Those toolkits should already have implemented what Aleksandar suggested; if they didn’t, file a bug report with them and/or fix it in the code yourself.

The actual problem this thread was created to solve, the gDebugger issue, is solved by doing what Aleksandar said.

The actual problem this thread was created to solve, the gDebugger issue, is solved by doing what Aleksandar said.

It’s partially solved. The cause of the problem was not solved. I still get the same error for the context creation calls…if this is the way to do it, why should it be reported as an error???

There are two possible reasons:

  1. Error in gDEBugger
  2. Error in your code

There is only one function you should use for context creation, and that is wglCreateContextAttribsARB(). The pointer should be grabbed while a temporary context is active. All other (GL 3+) contexts should be created while temp. context is active. End of the story. If you don’t call wglCreateContextAttribsARB() later, and why should you, gDEBugger cannot report error, since the function is called in the same context the pointer is grabbed.

Yup I could get rid of the errors as you suggested. Another problem occurs when calling glGetError just after creating the context and making it current, it return INVALID_ENUM before making any OpenGL call. The gDebugger seems failing to find the prob…

I bet you called glGetString(), though

It’s glGetError() what I’m calling. BTW this weird error I’m getting is when using core profile only. Another weird error the gDebugger cannot detect, but stops without reporting the reason. It only says First chance exception…

Ok problem solved. The big bug was hiding in the GLEW, it calls glGetString(GL_EXTENSIONS) on core profile…lol

Yeah, but this isn’t any news at all. It’s widely known that GLEW isn’t core profile ready and that the author(s) have has this on their todo list for a long time. Even AMD advertised against the use of GLEW when using the core profile. For a core GL ready loader you may want to try gl3w. It’s totally sufficient for 99% of use cases.

I may run my own API function loader, but is there any gl.h and wgl.h updated to 4.2 API?

You actually need glext.h and wglext.h. The up-to-date version of those files can be found on http://www.opengl.org/registry/

Thanks a lot!

Here you go
http://www.opengl.org/wiki/FAQ#Where_can_I_download.3F_.232

While struggling with running my own OpenGL API loader, I encountered a weird problem with wglext.h. It cannot see any windows.h types, such as HGLDC, HDC, …etc. Besides there’s still no clean gl.h for version 4.2. I have to use both gl3.h and glext.h to get all the required function pointer definitions.

It cannot see any windows.h types, such as HGLDC, HDC, …etc.

Why do you need wglext.h?

I need to load mainly the following wgl functions:

wglMakeContextCurrent
wglDeleteContext
wglCreateContextAttribsARB
wglChoosePixelFormatARB
wglGetProcAddress

And of course the macro defs/constants.