44
\$\begingroup\$

I'm new to 3D OpenGL/DirectX world and I found out that OpenGL 4.1 and GLSL specifications were just released today.

A friend of mine gave me the Red Book for OGL v2.1 but, as far as I've read, 3.x and 4.x differ a lot from 2.x and a lot of things are deprecated now.

Can I use the book to start learning the basics of 3D and CG or is it better to find a newer copy?

\$\endgroup\$
2
  • 10
    \$\begingroup\$ I don't know much about OpenGL/DirectX, but I do enjoy playing games on a machine that's more than a year old. I'd imagine your knowing pre 3.x OpenGL would be beneficial to my gaming habits. Just a thought. \$\endgroup\$
    – Simurr
    Commented Jul 26, 2010 at 18:49
  • \$\begingroup\$ I don't like the way this question is phrased. Can you make a game in OpenGL 2.1? The answer: a definitive Yes. What do you mean by useless then? Can you learn the basics of 3D from an older book or outmoded API? Again a definitive yes. Is it the best-best-bessssssst way to do it? Probably not. \$\endgroup\$
    – bobobobo
    Commented Feb 4, 2013 at 23:15

10 Answers 10

19
+50
\$\begingroup\$

In times like this I always head for the Steam Hardware Survey: http://store.steampowered.com/hwsurvey/ - you'll see that market penetration of DX10/11 class systems is at almost 80%; this being broadly equivalent to GL3.3 or above. This 80% is restricted to Vista/7 users - add in a DX10/11 GPU with XP and you rise to just over 90%.

Bearing in mind that we're talking about slightly more hardcore gamers here, you then need to start thinking about your target audience. Are these the people you want to target? Are you aiming at those with more downlevel hardware instead? What about Intel graphics? What about Mac and Linux users? These are all questions that you need to answer for yourself, so broadly general guidelines are the best you're going to get.

Adding to that, you need to take account of the fact that if you're starting to learn today with the intention of shipping something, you're looking at a period of about one year minimum before you get there (unless we're talking about really trivial/simple cases). With the upward trend of gfx capabilities continuing, we're looking at being real close to 100% uptake of GL3.3+ hardware by then.

Then factor in that with GL2.1 or lower you're going to be learning and using an awful lot of crufty old nonsense, even if you restrict yourself to the shaders and VBOs subset of GL2.1 (downlevel GLSL versions are nasty to use, and streaming VBOs are all but unusable without GL_ARB_map_buffer_range) - GL3.3+ has introduced much nicer (and more performant) ways of handling many things, you'll be making better use of the player's hardware (and they'll be grateful to you for that) and you'll be spending more time writing productive code rather than fighting an API that really doesn't want to co-operate with you.

And then of course there's the dreaded driver situation. The hard but true fact is that GL drivers on Windows are in a sorry state - NV support things they shouldn't, AMD don't support things they should, and with Intel you really need to restrict yourself to GL functionality for which there is an equivalent in D3D. The newer the GL_VERSION is the more likely it is you'll encounter driver bugs, but for GL3.3 things are reasonably stable now.

So the summary is that, in the absence of any other info (target audience, etc), I'd target GL3.3 as a baseline (possibly pulling in functionality from higher GL_VERSIONs where it's available and where it doesn't disrupt the codebase too much) unless there was a very specific and definitively identified reason to go any lower (and I'd want to be absolutely 100% certain of that rather than using some vague notion of "but what about those with older hardware"). In the latter case I wouldn't go below GL2.1, and I'd look to pull in as much 3.x functionality as possible even then.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ Great point on GL3.3 ~= DX10/11 and Steam hardware stats. \$\endgroup\$
    – Nate
    Commented Aug 23, 2012 at 16:54
  • \$\begingroup\$ Just to update these stats - DX10/11 GPU + Vista/7 are now at ~88%, add in another 4.38% for DX10/11 GPU + XP and you're looking at quite comfortably over 90% penetration. Uptake is rising a lot faster than I had anticipated when I made that original post. \$\endgroup\$ Commented Sep 20, 2012 at 0:16
  • \$\begingroup\$ "GL3.3+ has introduced much nicer (and more performant) ways of handling many things" - How does 3.2 fare in comparison? Mac users don't get 3.3 yet. I've been assuming it's almost the same, but don't want to assume too much. \$\endgroup\$ Commented Nov 1, 2012 at 16:31
38
\$\begingroup\$

I would suggest sticking with the intersection of 2.1 and 3. There is still a lot of hardware and drivers that only support OpenGL 2.1, but the practices encouraged by OpenGL 3 core are better. This tutorial is a pretty good place to start (teaches OpenGL 2.0 without features that have been deprecated in 3).

\$\endgroup\$
1
  • 3
    \$\begingroup\$ +1 for the Joe Groff tutorial. He takes you through the whole pipeline in Chapter 2. And any "utility" code he adds on is just two functions: one to read in a file (for GLSL) and one to read TGA images (and you could just as well use another image library or write your own image loader once you've gotten the example working). Everything else is explained and part of the tutorial. \$\endgroup\$ Commented Dec 9, 2011 at 10:35
18
\$\begingroup\$

I would say it's not useless.

Why? Well, while the rest of the world is supporting OpenGL 3.x and 4.0, Mac OS X still only supports OpenGL 2.1. And, OpenGL ES, which is used on most, if not all, portable platforms, is still widely supported at all versions: 1.0, 1.1, and 2.0; which are roughly comparable to OpenGL 1.4, 1.5, and 2.1, respectively.

So until OpenGL ES 1.0 disappears completely from the face of the Earth, knowing OpenGL 2.x will not be a waste.

That's not to say there isn't value in using OpenGL 3.x or 4.0 on platforms that support it, of course.

Update: As of the release of Mac OS X Lion (10.7), OpenGL 3.2 Core profile is now supported on the Mac. This release deprecates large parts of OpenGL 1.x to simplify the API. Users of older versions of OS X (and low-end Intel graphics) are still limited to OpenGL 2.0 and 2.1. Knowing OpenGL 2.x is nevertheless still useful, and will remain so for quite some time.

\$\endgroup\$
3
  • \$\begingroup\$ Snow Leopard does support most extensions of OpenGL 3 - even geometry shaders. \$\endgroup\$ Commented Jul 26, 2010 at 18:58
  • \$\begingroup\$ @Alex Supporting "most"extensions doesn't mean core GL3 is supported. And we're just talking about 3.x \$\endgroup\$
    – Dr. Snoopy
    Commented Jul 26, 2010 at 19:09
  • \$\begingroup\$ @Axel Gneiting: It's just not the same. Most of the interesting features of OpenGL 3.0+ aren't available as extensions. There are a large number of core changes. \$\endgroup\$
    – greyfade
    Commented Jul 26, 2010 at 19:45
11
\$\begingroup\$

mh01's answer covered much of the basics, so I'm going to add a few suppliments.

OpenGL ES

Let's talk about about ES 2.0 vs. desktop GL 2.1 vs. desktop GL 3.3. For the purpose of this discussion, the term "GL X.Y" will refer to the desktop OpenGL version X.Y, while "ES X.Y" will refer to OpenGL ES X.Y.

Structurally, ES 2.0 has more in common with core GL 3.3 than it does with GL 2.1. GL 3.3 and ES 2.0 are both pure-shader based. They're both pure buffer-object based. Etc. GL 2.1 has many performance and coding traps that would make it easy to write a GL 2.1 app that wouldn't easily be portable to ES 2.0.

However, in terms of shading language syntax, GLSL ES 1.00 (mapping to ES 2.0) looks much more like GL 2.1's GLSL than GL 3.3's. The attribute and varying keywords don't exist in 3.3 core; it uses in and out, which is a lot more consistent and reasonable when you're dealing with more than 2 shader stages (which is why ES 3.0 adopted the GL 3.3 syntax).

It is easy to map the concepts learned in GL 3.3 to ES 2.0. So if you learn GL 3.3 for any of the various tools for doing so, you'll understand how to work in the ES 2.0 world. You'll need to figure out where the subset is, of course (ie: the things that GL 3.3 can do that ES 2.0 can't), but the concepts are the same.

Mapping GLSL's syntax, so that you can copy shaders from one to the other, is a bit harder. But really, all it takes is a few #defines in the right places. Also, GLSL 3.30 has a few ES compatibility features, like highp and so forth (which do nothing in desktop GLSL).

So you do gain something for ES 2.0 when learning from GL 3.3 instead of GL 2.1.

\$\endgroup\$
8
\$\begingroup\$

For games that do not require the larger changes to OpenGL exposed only in the newer versions, using only 3.x+ limits you to an nvidia 8 series and upwards (not sure on the other graphics vendors you'd want to look that up). So if you're not using 3.x+ features, you're just creating an artificial limit, stopping people with older, but plenty powerful, graphics cards from playing your game.

For this reason I'd highly recommend learning the forward compatible subset, and the newer versions, then picking the lowest version you can effectively push your game into. You can

I will also note in response to another question that OpenGL:ES 2.0 removes the fixed function pipeline, so it's more equivalent to 3.0 than 2.1.also always support different features per the supported gl version at runtime.

\$\endgroup\$
4
\$\begingroup\$

I would say it's save to learn OpenGL using your Red Book, just ignore those things that are deprecated in the newer versions (like glBegin(), glEnd() - use VBO's instead). Most of the functionality in the newer versions was already available before through extensions.

\$\endgroup\$
4
\$\begingroup\$

I mostly agree with thbusch. But I would not completely ignore the deprecated APIs: there is too much code still out there that uses them. I would pay them much less attention, though. No point, for example, in learning glBegin(), glEnd() thoroughly enough to write your own code using them. But you should recognize them when you see them, and have some idea of what they are doing.

It is still worth reading through the whole Red Book at least once, even if you don't build the sample code and do exercises covering features discontinued in OpenGL 3.x.

\$\endgroup\$
3
\$\begingroup\$

The short answer:

No. Learning OpenGL 2.1 is a good idea, even today, as long as you learn the "good parts".

The Long answer:

OpenGL can essentially be divided in two parts: "The good parts" and "Legacy functions".

Honestly, I don't see much benefit in learning legacy functions (the "fixed function"). However, a substantial portion of OpenGL 2.1 (the good parts) are still available today with relatively minor changes.

As such, learning some parts of OpenGL 2.1 can be beneficial. In particular, OpenGL ES 2 is very popular these days, and ES 2 is mostly (but not exactly) a subset of OpenGL 2.1. For 3D programming in smartphones, OpenGL ES 2 is a must.

So what's "good"? Essentially anything that is in OpenGL 3.x "core profile" (as opposed to "compatibility profile") and/or in OpenGL ES 2.

  • Vertex and fragment Shaders: Learn them
  • Textures: Still good.
  • Matrixes: Knowing how they work is beneficial, but glLoadIdentity and that sort of functions are outdated and should be avoided
  • Light: Knowing how light can be simulated in computer graphics is useful, but glLightfv and other fixed function light functions should be avoided.
  • Array buffers: Good
  • glBegin, glVertex, glColor, glEnd: Avoid them. Might be good for quick experimentation, but there are other better ways to do the same.
  • Display lists: Avoid

The question where I originally posted this answer turned out to be a duplicate, so I'm reposting it here.

\$\endgroup\$
1
\$\begingroup\$

I don't believe it is a bad idea. A lot of GL concepts span across all versions of OpenGL and will still ultimately help you. I have a number of OpenGL books from 10 years ago that still help today. I would say that if you are new to OpenGL and there are some better books that are older, you will learn plenty and the code should still work. Most of OpenGL is backward compatible (I believe).

\$\endgroup\$
1
\$\begingroup\$

I advise that you learn the modern stuff first and just pretend the legacy stuff doesn't exist until you need it.

The out of date stuff can be useful in some cases for example if you are trying to program for something only supporting OpenGL 1.5 or older (can be found on older crappy netbooks and older MacOS systems), OpenGL ES 1.x (the older iPhones and Android before 1.6), or OpenGL SC (The Saftey Critical subset if you happen to be programming a display on jet fighter). Minecraft for example is built against OpenGL 1.3 so it can support really old hardware (but even that does have an 'advanced' option).

It can also be useful if you just want to get pixels on the screen and don't care about doing it the 'right' way.

It is useful to rely on some of the features that OpenGL does by default when learning such as setting up a -1.0 to 1.0 viewport and rendering without shaders. This allows you to learn without having to do everything in 1 go.

But other than that it should be skipped if possible.

I suggest you check out my answer's here and here for more in-depth information.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .