Look at the whole lot of mobile devices. I have no numbers to base this statement on but I would be bold enough to claim that OpenGL is thanks to the multiplatform ability by far the most successful graphics API out there. The set of devices that brings some or another form of OpenGL support outnumbers other graphics platforms. This alone is a huge accomplishment. Heck, even Minecraft was able to run on PowerPC systems until they pushed the java version supported.
But now I need to look at the link and have to admit that the criticism is still correct. The API is still pretty rough and could see some improvements. I know this myself, I also played around with OpenGL at some point. There is a lot of boilerplate code that needs to be written before you can start yourself with the real game. This was always the case. This is why we always had an engine, a framework to built on.
But to say that it all is a huge pile of shit is a little bit harsh …
OpenGL is almost like the IE of graphics development. You usually have to support it because it's so ubiquitous, but it constantly makes you want to tear out your hair because it does so many unexpected things and you have to memorize 5000 little caveats.
If you think what browsers do is easy... :-)
Here's the thing though: most of what OpenGL screws up is the not-hard stuff. Here are the main things wrong with OpenGL right now:
* Everything operates on and modifies implicit global state, especially with the various "bind" patterns (direct state access will help a lot with this). Even a first year CS student knows global state is bad. It was sort of acceptable-if-ugly back when the fixed function pipeline was the thing, but for almost the last 10 years that's been deprecated, and with how you program a GPU now that global state and bind patterns is ridiculous.
* Error handling is unfriendly and confusing and slow. It's very easy to accidentally send in a bad parameter to a function, have OpenGL silently ignore it, only for something to blow up in your program in a completely different module because that error went silently unchecked. This is just bad. Not only that, but glGetError rarely gives you any useful information. Why can't it at least tell me what function failed, and which parameter/value it was that made it fail? A lot of times you'll see an error in a complex function like glTexImage2d that has a ton of possible parameter combinations for "invalid value". Well, which one is invalid? What inputs would be valid? The driver knows, so why can't it tell me?
> Not like IE which was/is stagnant because of big company sluggishness/exceptionalism, but because its open source trying to do a huge amount with limited resources.
Have you looked at the companies that comprise the khronos group? They're not exactly poor. The problem isn't resources, it's bad design by committee.
Nvidia have been pushing for bindless graphics.
OpenGL is a graphics library (and a rather low-level one too), so it has very little to do with games. It's only a specification for the wrapper above the gpu hardware.
- Font loading
- Texture loading
- Shader loading
- Math library
- Geometry loading
- Integration with the OS UI
- Debugging capabilities
- glm for math (http://glm.g-truc.net/0.9.5/index.html)
- gli for texture loading (http://gli.g-truc.net/0.5.1/index.html)
- assimp for general asset loading: http://assimp.sourceforge.net/index.html
- the STB headers (not OpenGL specific): https://github.com/nothings/stb
- GLFW as window system glue and input wrapper
- ...and more which I am not aware of or forgot to list
GPU vendors also have SDKs and especially debugging tools (e.g. NVIDIA nSight which integrates into VStudio). It's not in one place like in DirectX, but on the other hand, the OpenGL world has a lot more platforms and usage scenarios to cover then D3D or the various new-style APIs like Metal or Mantle (these are the actual motivation for OpenGL-Next, reducing overhead even when this means a lower-level API which is even more focuses and harder to use then before).
Game console APIs.
> In D3D this used to be offloaded into a separate D3DX API, but AFAIK this is no longer supported in Windows8
DirectX is now integrated into the Windows SDK and makes use of new APIs:
Math is provided via DirectXMath.
Shaders can still be combined via Effects.
Interactions with the windowing system are done via DXGI.
Image loading is done via Windows Imaging Component.
> For OpenGL there's plenty of libraries to choose from, for instance:
Yes, I had to go library hunting already a few times. It gets tiring trying to see what are the current ones for people like myself that only occasionally do graphics stuff.
For example, a few years ago DevIL was the library to go for image loading.
SDL2 is cool, and so is @icculus. It isn't everything he wants, by a long shot, but it's good at what it is. I used SDL2 for a while when writing my game engine in C++ and didn't port to Mono for any reason related to it (just a burning desire to have a scripting layer that wouldn't make me put my head in an oven.).