Hi all! Currently Im learning OpenGl 3.2, but maybe I should learn OpenGL 2.1.
OpenGl 3.2 is modern, so it may improve rendering performance(if you using it right).
But I don’t know how much machines support OpenGL 3.2 and which one should I use?
I will use this for game development, so I want to my game be as much compatible as possible.
both, 3.2 and 2.1 are outdated, you should learn “modern” OpenGL, starting with version 3.3
http://www.opengl-tutorial.org/beginners-tutorials/tutorial-1-opening-a-window
To give you an idea of OpenGL support and to help you make a better decision:
[ul]
[li]OpenGL 2.x is available virtually anywhere. Graphics cards came out in 2004-2005, and even 2006 Intel chips have support. The problem is that OpenGL 2.x is really dated (it’s called legacy for a reason) as it lacks features indispensable for today’s graphics (FBOs, VAOs, Array Textures, Instanced Rendering…).
[/li][li]OpenGL 3.x is supported on 2007-2008 hardware. That’s where things start to become complicated with Intel hardware; but people with integrated graphics from before 2011 should know. Has all the good stuff you need for modern OpenGL development.
[/li][li]OpenGL 4.x is supported on 2010-2011 hardware (GTX 400 and Radeon HD 5000), and has even more features you don’t know you want them yet™ (Indirect drawing, Tesselation, Immutable Storage, Compute Shaders, SSBOs, Direct State Access…) but there’s still problems with Intel (support varying on OS), OSX (4.1 maximum supported) and AMD is a bit late to the 4.5 party.
[/li][/ul]
You should start with 3.3 going up to 4.5 since the latter is quite advanced and mostly adds features on top of 3.3. Also if you absolutely need compatibility, ‘downgrading’ is easier to manage.
Keep in mind you’re just starting to learn OpenGL now; it will take one or more years to make something of it. Not to discourage you, but older hardware will become obsolete and people will replace it. If you really need a maximum version number it should be OpenGL 4.4. No direct state access but widely supported on <5 year hardware.
What the others said is all true. I just want to add that OpenGL is only a tool. You should use it as much as you actually need it. Look at the kind of application you want to develope and then decide what tool is best suited to get things done.
If you want to create a more sophisticated 3D video game the newer versions of OpenGL are definitely a good pick.
But if you just want to create a simple 2D game in the style of old arcade or early console games then the newer OpenGL versions will not add many features you will actually need or want. You could do that with older OpenGL functions too (which are also easier to understand for a beginner).
Perhaps you should even evaluate whether OpenGL is the right tool for the job. It might be a better idea to look for a higher level graphics framework instead.
The main thing is to learn at least OpenGL 2.0 and to avoid using legacy features (those which aren’t available in 3.2+ core profile). If you don’t see a function listed in the OpenGL 4 reference pages, don’t use it.
Most of the features which were added after 2.0 can be compartmentalised (i.e. you don’t need to know about a feature unless you actually use it). The main exception is vertex array objects (VAOs); OpenGL 3+ core profile requires that a VAO is bound, OpenGL 2.0 behaves as if there’s a single default VAO and it’s always bound. But the difference between code which works with OpenGL 2.0 and code which works with OpenGL 3+ core profile can be as little as creating and binding a VAO (two function calls) in the initialisation function.
Okey, thanks for help and explanation. I think I will choose OpenGL 3.3 for now, it has everything what I need.
To add a rather different opinion… I say that if it’s possible, learn OpenGL 4.5. Why?
Because it’s the OpenGL version that makes the most sense.
OpenGL has had a lot of stupid bits in it since Day 1. But over time, new APIs replaced the old. And while 3.1 may have jettisoned some of the truly ancient stuff, the 4.x line has continued to add features to OpenGL that have nothing to do with hardware.
The ability to specify uniform locations in shader. The ability to specify sampler bindings from shaders. The ability to select components from vertex shader inputs/fragment shader outputs. A reasonable API for introspecting shaders. Separate shaders and program pipeline objects. Immutable storage textures and buffers.
Everything about direct state access.
None of those things are hardware features (well technically, immutable buffers are bound to persistent mapping which is a hardware feature, but nevermind that now). But all of them massively contribute to the overall quality of life that you have as a programmer. They change the way you code.
Let me give you a simple quality-of-life example. In OpenGL 3.3 up through 4.4, if you want to attach a face of a cubemap to an FBO, how do you do it? Do you use glFramebufferTextureLayer, like with cubemap array textures? No; you have to use glFramebufferTexture2D. Why? Because you have to specify a cubemap face target, to select which face to pick from. Even though glFramebufferTextureLayer could do it (as proven in 4.5 where it does), it’s not allowed because… well, it was just something no one on the ARB ever fixed.
Pre-4.5 OpenGL has tons of oddities and inconsistencies like that. Specifying complex transform feedback scenarios through glTransformFeedbackVaryings is a byzantine process. It wasn’t until GL 4.4 when they made it all simple and obvious.
OpenGL 4.5 is the first version of the OpenGL API that one could reasonably call clean. Or at the very least, you have the ability to do everything in a way that is clean.
The only downside to it (besides being restricted to a 4.5 implementation) is that you have to learn without a net. Sadly, nobody writes tutorials exclusively for OpenGL 4.5.
Not every device supports OpenGL 4.5. I will use OpenGL for 2D project, all what I need at this time is to implement basic OpenGL functions, to draw texture. I won’t use OpenGL 4.5 because, this won’t take much time to implement these functions, and I want make my game to be compatible with many machines also in 2D rendering performance is not a problem, so I not forced to use most newer opengl version to get best performance.
Supporting every device is not a realistic objective. You’re learning; set yourself goals you actually can achieve.
Well, if you use OpenGL 1.1, you’d be hard pressed to find any device supporting any OpenGL version where it doesn’t work. More generally, the older the OpenGL version, the more devices will support it.
Now, using anything before 2.0 is going to preclude the use of shaders (unless you use the vertex/fragment program extensions, which is a lot of hassle for very little gain). But (excluding the specific case of GLX indirect rendering) 2.0 will work on practically anything found outside of a computer museum, so long as you don’t use a 3+ core profile. Sure, some of the later versions added some useful features, but the changes from 2.0 to 4.5 are still minor compared to the introduction of the programmable pipeline.
And it’s not exactly hard to write code which will work with both 2.0 and 3+ core profile (i.e. if VAOs exist, create and bind one, then forget all about them). Such code may even work with OpenGL ES 2.0 (which lacks legacy OpenGL but also lacks VAOs).
I’d also suggest that until you’ve had some amount of experience of dealing with versions (e.g. knowing which OpenGL version your program requires, or being able to make decisions about the minimum version worth supporting), you haven’t actually learnt OpenGL yet.
What isn’t worth learning initially is legacy OpenGL. By which, I mean everything that was actually deprecated in 3.0: fixed-function pipeline, glBegin/glEnd, glRenderMode, etc, not the bits which have merely been superseded by cleaner and/or more flexible interfaces to substantially similar functionality.
There’s still some merit in learning that stuff eventually, if only because such code exists, and some of it is still useful. Practical programs will eventually get converted to modern OpenGL (although doing so requires an understanding of legacy OpenGL), but books, academic papers and articles aren’t going to get re-written.