[fixermark]

Quite a few of these issues (especially in the "Too many ways to do the same thing" category) relate to OpenGL's age as an API, which is something Direct3D's design was able to learn from and improve upon. OpenGL's origin was as a vector-based drawing tool for CAD applications which was repurposed to games; D3D was targeted for performant rendering with games as a specific target. This is demonstrated by some key features necessary for performant games (clock synchronization to avoid 'tearing' comes immediately to mind) that are core to the D3D spec and extensions to the OpenGL spec. There's also a bit of a cultural issue; if you learn OpenGL from the 'red book,' you'll learn the function-per-primitive API first, which is precisely the wrong tool for the job in making a performant game. Really, the OpenGL API is almost multiple APIs these days; if you're using one flow of how to render your primitives, the other flow is downright toxic to your rendering engine (in that it's going to muck about with your GL state in ways that you shouldn't burn mental energy predicting).

Some of this is ameliorated by the OpenGL ES standard, which throws away a big chunk of the redundancy. But I'm not yet convinced that OpenGL has gotten away from its philosophical roots as a performance-secondary CAD API, which continues to dog its efforts to grow to serve game development needs. The fact that it's functionally the only choice for 3D rendering on non-Windows platforms is more testament to the nature of the hardware-software ecosystem of graphics accelerators (and the creative doggedness of game developers) than the merits of the language.

[gaustin]

I dabbled with the Red Book aeons ago, but never got very far with 3D programming. What would you suggest for learning OpenGL? Or is there some other tool you'd recommend learning?

[yoklov]

This is the list I typically see given to newbies (on freenode ##OpenGL, and /r/opengl) wanting to learn modern OpenGL.

1. Arcsynthesis's gltut (http://www.arcsynthesis.org/gltut/) is good and reasonably thorough. He explains things well but not always in the order you'd like him to. At the end you will probably know enough to be able to figure out the rest on your own as you need.

2. http://open.gl/ is good but somewhat short. It also goes in depth into creating/initializing a context with various APIS (SDL, SFML, GLFW, ...). More of a good starting point than a complete guide.

3. http://ogldev.atspace.co.uk/ has a lot of good tutorials on how to do more advanced techniques, as well as many beginner level tutorials. I've never gone through them so I can't speak to their quality, but I've heard good things.

4. http://www.lighthouse3d.com/tutorials/glsl-core-tutorial/ is also good, but focused on the shading language.

See /r/opengl and freenode's ##OpenGL channel for more. Both those places are fairly newbie friendly (/r/opengl moreso than ##OpenGL, but as long as you actually know your language of choice they're nice), so feel free to ask questions.

[nitrogen]

For OpenGL 1.2 there was nothing better than http://nehe.gamedev.net/ (e.g. http://nehe.gamedev.net/tutorial/lessons_01__05/22004/), but I don't know if something similar exists for modern OpenGL.

[cyphax]

I remember this link being posted recently and since I have some interest in looking into this area as well, it stuck with me (and a browser tab ;) While it's not a tutorial or anything, the article addresses the question "where do I start?" and mentions (not only in the title) "modern OpenGL" specifically.

http://www.codeproject.com/Articles/771225/Learning-Modern-O...

[greggman]

I'd recommend starting with WebGL. It's the same API minus the cruft. You can use it nearly anywhere.

Here's some tutorials I wrote to hopefully make it clear how things work

http://games.greggman.com/game/webgl-fundamentals/

Everything you learn there will be directly applicable to C OpenGL

[higherpurpose]

I hope Khronos focuses on making OpenGL ES the true "next-gen gaming API" as a clean departure from the full OpenGL, and they also get a chance to "rewrite", perhaps in a more efficient manner, the features they've already written for OpenGL.

In the meantime they can continue improving OpenGL, too, but without focusing too much on it, and just kind of let it deprecate itself, as OpenGL ES sits on billions of devices and developers develop only for it and not for the full OpenGL anymore.

[yoklov]

OpenGL ES isn't really a departure from OpenGL, and most of the problems with OpenGL (all the ones mentioned here, I believe) apply to OpenGL ES.

OpenGL ES isn't trying to be a clean break. It's just a stripped down version of the given version suitable for embedded environments (e.g. OpenGL ES 2 is a stripped down version of OpenGL 2.0, ES3 => 3.0, ...).

[bostik]

GLES also introduces a logical split between memory management (buffers, surfaces) and rendering/acceleration.

The traditional OpenGL drivers have everything in a single near-monolithic bundle. Low-level memory management is tightly coupled with the high-level 3D primitives and the graphics driver implementation.

With OpenGL ES, the actual buffer and surface management has been split into EGL. GLES has the "useful" GL implementation.

My understanding is quite limited, as the only reason I know about this is that I have been involved in integrating Wayland into embedded systems.

[Aardwolf]

It would be interesting if they made a high-performance variant of the red book using the latest standard, e.g. the "bright red" book or "crimson book" or so :)

[fdr_cs]

Both 5th and 6th editions of OpenGL Superbible use only Core Profile functionality. It's the best way to start OpenGL nowadays

[TuringTest]

Something like this? http://www.arcsynthesis.org/gltut/

[criley2]

Companies like Sony use in-house custom versions of OpenGL for their API's.

They support OpenGL but aren't using it out of the box for their toolset.

See: libgcm, gnm, gnmx. Although I'm not positive that gnm/gnmx are opengl derivative.

Also see: http://develop.scee.net/files/presentations/gceurope2013/Par... (pdf warning)

[jblow]

They are not OpenGL derivative. I don't know why this rumor propagates. Oh wait yes I do, because those of us who know what the APIs look like in detail generally can't say anything about them because of NDAs. Sigh.

To be clear: None of the APIs you listed are based on OpenGL. PSGL was an OpenGL implementation, but nobody writing a high-performance game used it because it was too slow and unreliable. The APIs used by almost all shipping games you can think of are substantially lower-level.