This aspect has been bothering me for a while now: what are the differences I need to be aware of between OpenGL 2.1 and 3.0? I do know that 3 introduces a deprecation mechanism, but what types of functions have been deprecated? I’d like to know this so that I can look for OpenGL resources without having to be worried about whether a certain feature/practice is “deprecated” or not. I also don’t really want to run away from tuts that use OGL 2 if there’s still valuable information that applies to OpenGL in general.
Another thing I’m wondering about is how I can present newer OGL 3+ projects on older PCs that don’t support it. What compatibility methods should I use to get the most benefits out of 3.0+ while still maintaining compatibility with older systems? Or will I have to resort to finding a capable PC to present my applications?
OpenGL 3.0 introduced a number of features. Some of them are based on hardware; others can work on older hardware. For hardware to expose OpenGL 3.0, it must expose all of it. Therefore, it needs to be OpenGL 3.0-capable hardware (equivalent to D3D10 hardware).
If you are creating a project that you want to be able to run on hardware incapable of OpenGL 3.0, then I would suggest that you not write applications for OpenGL 3.0.
Many of the features of 3.0 that can be used on older hardware are backported via extensions. So instead of writing a 3.x application, you should be writing a 2.1 application that is able to use certain extensions.
What compatibility methods should I use to get the most benefits out of 3.0+ while still maintaining compatibility with older systems?
The general method is to have different rendering paths for different features. You detect the version number. If it’s one thing, you use one rendering path. If it’s lower, you use another. Etc. You can do fine-grained checking by checking for the presence of certain extensions. It’s generally a big pain to do this, but it is necessary to support a broad range of hardware.
The other alternative is to limit yourself. If the bare minimum you support is 2.1, then code to 2.1 and only 2.1. Don’t use anything (except extensions) that isn’t part of OpenGL 2.1. This is easier to do as you only have one rendering path. But you can’t take advantage of higher level features.
I don’t know what you mean by “present my applications.” Are you just using OpenGL to give presentations, or are you giving other people your application?
My main goal is to publish video games (I’m sort of a self-training indie developer), but also to present the work I’ve done to others, and perhaps for a future portfolio. I suppose that’s what I mean by “presentation”.
I’m starting to like the idea of having two rendering paths. I could make some graphics wrappers and use those to encapsulate various collections of dynamic libraries (holding the platform-specific functionality), depending on the OGL version supported. That way my code will be lighter and I can leave it to an installer to provide the correct libraries depending on the system specs.
This might be a bit more work, but it does give me a better perspective of how I should manage the platform-specific code. I suppose the real question is how to write these theoretical “graphics wrappers”…
I’m starting to like the idea of having two rendering paths.
We’ll see how much you like that idea once you start implementing it
That way my code will be lighter and I can leave it to an installer to provide the correct libraries depending on the system specs.
That’s not a good idea. What happens if they upgrade their graphics card, for example? It’s better to just install all of the code (it’s not like it’s particularly large) and go from there.
This, 25,000 times over and with great hairy knobs on.
Maintaining separate rendering paths can be horribly painful, especially in cases where the differences are so great that everything you do, you effectively have to do twice.
If you’re concerned about supporting downlevel hardware, what I’d strongly recommend is forgetting about a dedicated 3.0+ path; just code to the GL 2.1 spec instead. You can always research the calls and features that have been since deprecated and just avoid using them in a pure 2.1 program; that way your code will be reasonably future-ready and you’ll be more easily able to make the jump in version 2.0 of your own program.
Okay, thanks for the warning. I’ll definitely look more into 2.1 (and possibly how it’s different from the newer releases) and probably make my decisions from there. Hopefully 2.1 is still capable of awesome graphics!
One other thing: are there any software-based implementations for the newer OGL versions? Software rendering would be good just to give a few IRL friends a glance at my 3.0+ stuff, but I wouldn’t use it for a full release.
It’s better to just install all of the code (it’s not like it’s particularly large) and go from there.
Will do, if I even consider multiple OGL versions again.
There is none, at least as far as I know.
But it is much better and easier for everyone just to send pictures, or even better record a video-clip from your desktop and send it to your friends. In any case, a CPU based implementation would not be better than a slide show.
I’m starting to like the idea of having two rendering paths. I could make some graphics wrappers and use those to encapsulate various collections of dynamic libraries (holding the platform-specific functionality), depending on the OGL version supported. That way my code will be lighter and I can leave it to an installer to provide the correct libraries depending on the system specs.
This might be a bit more work, but it does give me a better perspective of how I should manage the platform-specific code. I suppose the real question is how to write these theoretical “graphics wrappers”
