Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 7 of 7

Thread: How do I make sure my code is backward compatible?

  1. #1
    Junior Member Newbie
    Join Date
    Oct 2012
    Posts
    8

    How do I make sure my code is backward compatible?

    Hello, I'm rather vexed by all these different versions of OpenGL and the lack of information regarding writing good code that will give me decent backward compatibility. You see I'm planning on writing an application that will require atleast OpenGL 1.5 to function properly. However, I want it to utilize, if available, functionality from some newer version as well, mainly because I want the experience and an application able to run on older hardware.

    I read something about the older versions containing fixed functionality, something that was deprecated and removed in the newer versions, and some certain "state-based" versions that are unlike the newer ones. How do I make sure I'm not using something that is deprecated in the current version I'm working with? Do I simply tailor the thing I need to achieve by checking what tools are available dynamically?

    Regarding context creation, what "version of OpenGL" is a context made using the simple calls to ChoosePixelFormat(), SetPixelFormat(), wglMakeContext() and wglMakeCurrent()?

    What is the most sensible way to do this? Does anyone know of articles regarding this? Is the only way to read , page-by-page, each specification?

    I know I am probably answering myself but I'm still unable to do anything because I lack information.

    Thanks,
    monkey

  2. #2
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,126
    Quote Originally Posted by monkey View Post
    Hello, I'm rather vexed by all these different versions of OpenGL and the lack of information regarding writing good code that will give me decent backward compatibility. You see I'm planning on writing an application that will require atleast OpenGL 1.5 to function properly. However, I want it to utilize, if available, functionality from some newer version as well, mainly because I want the experience and an application able to run on older hardware.

    I read something about the older versions containing fixed functionality, something that was deprecated and removed in the newer versions, and some certain "state-based" versions that are unlike the newer ones. How do I make sure I'm not using something that is deprecated in the current version I'm working with? Do I simply tailor the thing I need to achieve by checking what tools are available dynamically?
    All that deprecation/removal stuff only applies if you explicitly allocate a "core" context. That prunes the API down to only "the new stuff".

    If instead you just create a "compatability" context (the default) -- e.g. normal glXCreateContext (on UNIX/Linux) or wglCreateContext (MSWin) -- then you get all the old stuff along with the new goodies. No worries. That's what I do.

  3. #3
    Junior Member Newbie
    Join Date
    Oct 2012
    Posts
    8
    Quote Originally Posted by Dark Photon View Post
    All that deprecation/removal stuff only applies if you explicitly allocate a "core" context. That prunes the API down to only "the new stuff".

    If instead you just create a "compatability" context (the default) -- e.g. normal glXCreateContext (on UNIX/Linux) or wglCreateContext (MSWin) -- then you get all the old stuff along with the new goodies. No worries. That's what I do.
    So, are there any performance hits if I use the "compatilbility" context instead of a "core" that is supported on the system running the application?

    EDIT:

    I found this older thread which helped me understand this core and compatibility business a bit more.

    Since a lot of stuff was removed in 3.1 I figured I could allow two possible contexts to be created during runtime, one for 2.1 and another one for 3.1 + future stuff depending on the hardware. Does this sound viable?
    Last edited by monkey; 10-06-2012 at 02:26 AM.

  4. #4
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,076
    Quote Originally Posted by monkey View Post
    Since a lot of stuff was removed in 3.1 I figured I could allow two possible contexts to be created during runtime, one for 2.1 and another one for 3.1 + future stuff depending on the hardware. Does this sound viable?
    On Windows you have to create GL 2.1 context first in order to access GL functionality required for the 3.0+ context. So, if the creation of 3.0+ context does not succeed just use previously created one. Otherwise, just destroy 2.1 context.

  5. #5
    Junior Member Newbie
    Join Date
    Oct 2012
    Posts
    8
    Quote Originally Posted by Aleksandar View Post
    On Windows you have to create GL 2.1 context first in order to access GL functionality required for the 3.0+ context. So, if the creation of 3.0+ context does not succeed just use previously created one. Otherwise, just destroy 2.1 context.
    Thanks, that got me started atleast.

    I decided to create an abstract base class "GLContext" which I would derive other classes from, such as GL2_1Context. They all implement the functions of GLContext which means I can fix and tinker for each version without having to change anything in my main code.
    Last edited by monkey; 10-06-2012 at 08:47 AM.

  6. #6
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,076
    Fortunately, I saw at a glance what you posted previously and I think it is not a wise decision. What would be the methods and attributes of your GLContext classes? The context should be seen only as a handle (attribute) in a Renderer class. On that way you don't have to use multiple classes for multiple versions. During initialization just get the highest supported version and according to that choose the rendering path. Also, make as few benches as possible, or the management of the code would be unsustainable.

  7. #7
    Junior Member Newbie
    Join Date
    Oct 2012
    Posts
    8
    Quote Originally Posted by Aleksandar View Post
    Fortunately, I saw at a glance what you posted previously and I think it is not a wise decision. What would be the methods and attributes of your GLContext classes? The context should be seen only as a handle (attribute) in a Renderer class. On that way you don't have to use multiple classes for multiple versions. During initialization just get the highest supported version and according to that choose the rendering path. Also, make as few benches as possible, or the management of the code would be unsustainable.
    I only planned on making atleast 2 derived classes, one for 2.1 (this is the minimum version I want to support) and one for 3.1+. I haven't worked much with OpenGL yet so depending on what I learn I might just scrap this.

    It was mostly just so that I could specify the different rendering paths without much bloat, not much else. The name GLContext might not have been the most descriptive, GLRenderer would probably have been better.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •