Hi,
Let’s suppose you’re writing an OpenGL program that uses a context created by another developer you don’t have access to.
Is there any way I can check if the current context supports legacy functionality or if it has removed legacy stuff? IIRC, checking the ARB_compatibility extension isn’t a failproof method because some vendors didn’t expose such extension even if they didn’t remove any functionality. If possible, I’d prefer to check for legacy compatibility without using WGL/GLX API calls, but just OpenGL calls.
Thanks a lot!
glVertexAttribPointer:
GL_INVALID_OPERATION is generated if zero is bound to the GL_ARRAY_BUFFER buffer object binding point and the pointer argument is not NULL.
This is legal in legacy OpenGL, so set up the state, make the call and check for errors.
[QUOTE=mhagain;1265012]glVertexAttribPointer:
This is legal in legacy OpenGL, so set up the state, make the call and check for errors.[/QUOTE]
Thanks a lot. Trying to even get a simpler solution, I’m wondering if issuing a glGetString(GL_EXTENSIONS) and checking if a GL error happened would be a failsafe way. According to the spec, GL_EXTENSIONS is a valid enum only for glGetStringi in core OpenGL 3.1 and higher.
Do you think this would be a failsafe way for checking if we’re running with full legacy compatibility? :
if ( ( OpenGL.major_version < 3 ) || ( glGetString(GL_EXTENSIONS) doesn’t generate an error) )
legacysupported();
else
legacydontsupported();
Step 1 is to check the OpenGL version, using the old glGetString approach. If the version is 3.0 or less, then there’s no distinction to be made. There is one caveat to this, discussed below.
If the version is 3.1, then check for ARB_compatibility; that was the only way for a driver to advertise that it still supports the old stuff in 3.1, so if it doesn’t, I would trust it even if it did allow some of the old constructs to work.
If the version is 3.2 or greater, then just ask. Call glGetIntegerv(GL_CONTEXT_PROFILE_MASK). If the value it returns contains the GL_CONTEXT_CORE_PROFILE_BIT, then you know the old stuff is gone. If it contains the GL_CONTEXT_COMPATIBILITY_PROFILE_BIT, then it’s there.
There is one issue: if the user used the forward-compatibility bit (which is different from a core context). In 3.1 and above, this doesn’t mean much (only a couple of features remain deprecated-but-not-removed-from-core). But in 3.0, if they use forward-compatibility, then it gets rid of the old stuff.
To test this, in GL 3.0, get the context profile mask (which was added in 3.0). If the bitfield contains GL_CONTEXT_FLAG_FORWARD_COMPATIBLE_BIT, then it’s a forward-compatible context, so it doesn’t contain the old stuff.
[QUOTE=Alfonse Reinheart;1265016]Step 1 is to check the OpenGL version, using the old glGetString approach. If the version is 3.0 or less, then there’s no distinction to be made. There is one caveat to this, discussed below.
If the version is 3.1, then check for ARB_compatibility; that was the only way for a driver to advertise that it still supports the old stuff in 3.1, so if it doesn’t, I would trust it even if it did allow some of the old constructs to work.
If the version is 3.2 or greater, then just ask. Call glGetIntegerv(GL_CONTEXT_PROFILE_MASK). If the value it returns contains the GL_CONTEXT_CORE_PROFILE_BIT, then you know the old stuff is gone. If it contains the GL_CONTEXT_COMPATIBILITY_PROFILE_BIT, then it’s there.
There is one issue: if the user used the forward-compatibility bit (which is different from a core context). In 3.1 and above, this doesn’t mean much (only a couple of features remain deprecated-but-not-removed-from-core). But in 3.0, if they use forward-compatibility, then it gets rid of the old stuff.
To test this, in GL 3.0, get the context profile mask (which was added in 3.0). If the bitfield contains GL_CONTEXT_FLAG_FORWARD_COMPATIBLE_BIT, then it’s a forward-compatible context, so it doesn’t contain the old stuff.[/QUOTE]
Thanks a lot. This certainly solved my question in great detail 