All the whining and complaining makes me wondering how anyone was able to write something with OpenGL at all. This is fascinating because a great amount of people were actually able to write awesome Games and Applications with this API.
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[1].
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 …
Well by that logic, IE is a great browser because a lot of people got some amazing applications to run on it despite the fact that it was a nightmare to develop for...
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.
What OpenGL does is hard - to make things worth fast across multiple platforms with backward compatibility. 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. There are always higher level platforms if you want something easier to work with, but you sacrifice a little speed.
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.
>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.
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.
What other APIs would that be which offer this functionality? In D3D this used to be offloaded into a separate D3DX API, but AFAIK this is no longer supported in Windows8 (at least in the WinRT API) and has been moved into separate mostly personal projects (e.g. http://directxtex.codeplex.com/). A 3D rendering API should only be concerned about efficient 3D rendering and not burden itself with specific resource file formats. For OpenGL there's plenty of libraries to choose from, for instance:
- ...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).
> What other APIs would that be which offer this functionality?
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.
Game console APIs have it easy though since they only support a single GPU and a single texture compression scheme. In the OpenGL world it is more tricky, especially on mobile since each GPU vendor used to only implement their own patent-infested compressed texture formats (this useless GPU-vendor-infighting held back OpenGL back more then anything else). And most of the Windows APIs you listed are not part of D3D, but either part of (what used to be) DirectX, or some completely unrelated part of the Windows API, and with this you've locked yourself into the Windows world. From your requirements it sounds like you're best served with SDL2 or a similar medium level wrapper API, at least if you want to support platforms outside of Windows.
I'd agree with this. He doesn't want a low-level graphics API, which is what OpenGL is. He wants everythng else around it. For what it's worth, I totally want that too. I'm just not blaming OpenGL for being a leg when I really want a tail.
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.).
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[1].
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 …
[1] https://help.mojang.com/customer/portal/articles/884921-mine...