Console developers don't get much choice: You pretty much must use D3D9, D3D11, GNM(X), etc.
Mobile's not much better: OpenGL ES for Android (which is a far cry from real desktop OpenGL - to the point that I consider it a completely different graphics API that just happens to confusingly reuse the names of some functions.) Maybe Metal for iOS.
Real desktop OpenGL is one of the few graphics APIs I've never been forced to use - so why spend even a single dev-month porting to it? Even games with OpenGL render paths may work better using their Direct3D renderers on Linux via Wine!
Even counting Linux/OS X, at this point I'm not even convinced OpenGL is actually the more portable API...
I've written an iOS app and the OpenGL code was (except very few ifdefs) identical to the desktop code. So I wouldn't say that ES is a completely different API, you can certainly reuse a lot.
Not even our shaders went unscathed - no rectangular matrix support (mat4x3? nope!), mandatory precision specifiers (lowp-highp), no Uniform Buffer Objects. Can't even call glTexImage2D on ES 2 without perfectly fine OpenGL code failing - because format !== internalFormat is forbidden (read: documented "must be the same"), and you were a good explicit OpenGL citizen and asked for something as horrifically complicated as format=GL_RGBA and internalFormat==GL_RGBA8. Multiple render targets? Are you out of your mind? We can't have that - goodbye deferred rendering, hello old school forward rendering!
Even your bread and butter - functions like glUniformMatrix3fv do things like just outright ignore the transpose parameter. This is extremely well documented: "Specifies whether to transpose the matrix as the values are loaded into the uniform variable. Must be GL_FALSE." ( https://www.khronos.org/registry/OpenGL-Refpages/es2.0/xhtml... )
I swear I've reused more code between D3D11 and PS4 codepaths than between OpenGL ES and OpenGL codepaths, and the d3d11 and ps4 APIs don't share a single common function name betwixt them!
I must assume going from OpenGL ES 2 to real OpenGL a bit easier - even if you're probably giving all the fast paths in the latter a wide berth in doing so. Or maybe OpenGL ES 3 is a bit closer to real OpenGL. But OpenGL ES 2 vs desktop OpenGL? They both render triangles, but beyond that, it's a crap-shot, and a lot of #ifdefs in my experience. Separate files, even. Not just a few.
EDIT: s/codepaths/apis/, finish summarizing my thoughts.
Yes, calling OpenGL ES "OpenGL" compatible is only true to the ears of those that never had the "fun" to write portable code across multiple GPUs.
At the end of the day, the code paths, extension support and driver workarounds are so many that one could just be coding against multiple APIs anyway.
That's stupid. Competent 3d on Windows is DirectX. Competent 3d on Mac/ios is Metal. Competent 3d on consoles uses their propriatary API. So, what is the point of OpenGL portability? Between Linux and Android? You _will_ have to switch API if you are making anything worthy.
That's some impressive graphics fetishism on display there. It's hard not to take offense at the comment that anything less is not "worthy". Not everyone is a AAA studio with an engine development team, nor should everyone hold themselves to those standards of engine performance.
OpenGL 3.3 is a pretty nice target. It's easy to port an OpenGL 3.3 game to a lot of systems, including mobile, since OpenGL ES 2.1 is pretty similar, and Windows XP, which cannot run DirectX 10. (This matters less as time goes on, but it's been an important point in certain markets in Asia.) So you can write the graphics code once, more or less, and run it everywhere, more or less.
The idea that somebody who chooses to do this is therefore not "competent" just boggles the mind. No point in deriding engineers who decide not to use the latest bells and whistles in the graphics pipeline. Maybe they just have other priorities.
(To clarify: the recommendation that everyone should just use OpenGL regardless of situation is, in fact, stupid. So I agree with that part. But it's equally stupid to say that everyone should use D3D12 / Metal regardless of circumstance.)
If you write an app based on Direct3D 9 or 11, it usually just works on any supported version of Windows.
I once wrote an app that uses OpenGL 4.0 (this one: https://github.com/Const-me/GL3Windows), and it only worked on half of my PCs. To make it work everywhere, I had to downgrade to OpenGL 3.0, and also implement S3 texture decompression on the CPU.
GL 3.x is my current go to for the case of needing simple immediate mode 3D rendering. But it's still Bring Your Own Matrices/Texture Loading/Text Rendering/Model Loading, and D3D9 + D3DX had that all in a nice package. Like I said, stitching this stuff together isn't the hardest thing ever, but it's nice to have a basic set of boilerplate that's idiomatically consistent and works out of the box.
Because OpenGL is a dumpster fire of conflicting information for a beginner. I've been looking for a decent opengl book for years, in vain. DirectX 9 was sort of the sweet spot, where the technology stabilized for a few years at something decent. Nonetheless, aside from dumping the useful parts of d3dx, DirectX 11 is a lot friendlier to work with.
Mobile's not much better: OpenGL ES for Android (which is a far cry from real desktop OpenGL - to the point that I consider it a completely different graphics API that just happens to confusingly reuse the names of some functions.) Maybe Metal for iOS.
Real desktop OpenGL is one of the few graphics APIs I've never been forced to use - so why spend even a single dev-month porting to it? Even games with OpenGL render paths may work better using their Direct3D renderers on Linux via Wine!
Even counting Linux/OS X, at this point I'm not even convinced OpenGL is actually the more portable API...