Results 1 to 5 of 5

Thread: Query legacy compatibility of current context?

  1. #1
    Member Contributor
    Join Date
    Aug 2014
    Posts
    52

    Query legacy compatibility of current context?

    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!

  2. #2
    Newbie OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,789
    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.

  3. #3
    Member Contributor
    Join Date
    Aug 2014
    Posts
    52
    Quote Originally Posted by mhagain View Post
    glVertexAttribPointer:
    This is legal in legacy OpenGL, so set up the state, make the call and check for errors.
    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();

  4. #4
    Senior Member OpenGL Lord
    Join Date
    Mar 2015
    Posts
    6,671
    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.

  5. #5
    Member Contributor
    Join Date
    Aug 2014
    Posts
    52
    Quote Originally Posted by Alfonse Reinheart View Post
    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.
    Thanks a lot. This certainly solved my question in great detail

Similar Threads

  1. How to get if current GL context is Core or Compatibility
    By Aliii in forum OpenGL: Basic Coding
    Replies: 5
    Last Post: 08-27-2014, 04:48 PM
  2. Replies: 16
    Last Post: 06-05-2012, 07:54 AM
  3. making a context current w/o a drawable
    By zen in forum OpenGL: Linux
    Replies: 7
    Last Post: 01-13-2004, 04:00 PM
  4. gl Current Context
    By mr_coolio in forum OpenGL: Basic Coding
    Replies: 4
    Last Post: 02-25-2003, 12:48 PM
  5. Current Context?
    By link19 in forum OpenGL: Basic Coding
    Replies: 1
    Last Post: 05-22-2001, 05:35 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Proudly hosted by Digital Ocean