Bug on Windows with OpenGL and enabling multisampling

It appears that there’s an order of operations issue where the context requires being set up for multisampling before being attached. The problem with that is that the call to OpenGLHelpers::isExtensionSupported needs to be attached and called from the GL thread to be able to work.

As it is now, glGetString (GL_EXTENSIONS) returns a null char*… so none of the multisampling functionality will ever pass.

The GL_ARB_multisample feature does show up in the extensions list when I call that and print it out from the GL thread.

I’m also not really sure how this logic - if (version >= openGL3_2 - makes any sense from a user’s point of view: there aren’t any larger enum values provided.

Aren’t we better off dropping the enum for explicit integers for maj and min at this point?

Thanks for reporting. The issue is that when creating a context specifying openGL3_2 we need to use the “compatibility” profile as this allows deprecated function calls (of which glGetString (GL_EXTENSIONS) is one). I’ve pushed a fix to develop here:

Thanks! I don’t believe I’ve encountered WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB before. I’ll have to check that out.

It’s one of the bits used in the WGL_CONTEXT_PROFILE_MASK_ARB attributes when creating a context using wglCreateContextAttribsARB():

https://www.khronos.org/registry/OpenGL/extensions/ARB/WGL_ARB_create_context.txt

Great, thanks. Also, just confirming that this change works on my machine.

1 Like