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

[QUOTE=monkey;1243163]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? [/QUOTE]

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.

[QUOTE=Dark Photon;1243174]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.[/QUOTE]

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?

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.

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.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.