That'd be stupid, OpenGL is easy to use, very useful, provides a lot of functionality and in practical terms it is still the most widely available API across platforms (even if not all platforms give you the exact same functionality but that was always the case with OpenGL anyway).
I for one am not interested in writing the same graphics code across multiple OSes and OpenGL provides a perfectly fine API for my needs.
In a haphazard, difficult-to-use way that lags the state of the art. Because Microsoft controls DirectX, they can look at what the GPU manufacturers are doing, draw up an API spec for the advanced stuff and the GPU manufacturers would hew to that spec. OpenGL is designed by committee, a committee largely staffed by ancient CAD software vendors who insist on backward compatibility and it holds the API standard back. There's a janky extension system in place to allow GPU vendors to add functionality -- in proprietary, mutually incompatible ways that require the developer to write multiple code paths per unit of extension functionality.
Plus there's GPU debugging support integrated into Visual Studio. OpenGL doesn't have nearly the tooling that DirectX does.
Honestly, OpenGL should have been
abandoned, and DirectX made the standard, 25 years ago. The only reason it wasn't was John Carmack, for the past 15 years even he's conceded that DirectX is the better API.
> I for one am not interested in writing the same graphics code across multiple OSes
Use a game engine. It's got back ends for DX, Vulkan, Metal, even OpenGL (although that may change).
If you must code to some 3D API, use DirectX. Natively supported on Windows, supported via DXVK on Linux and DXVK+MoltenVK on Apple (though Microsoft is working on native DX for Apple hardware, probably translating straight from DX to Metal.)
I disagree completely, i can whip out a quick tool for a bunch of tasks much faster using some adhoc OpenGL code than anything related to Direct3D. Direct3D might be easier in some scenarios like writing some rendering backend that you can then ignore and only use it via a layer (but then the same applies to any API, including Vulkan), but i find OpenGL way easier to work with directly than any other API.
> In a haphazard, difficult-to-use way that lags the state of the art.
Haphazard is subjective. I find OpenGL easy to use. As for the "state of the art", it isn't something i often even care to think about.
The only thing i found missing with OpenGL is raytracing support, though that is a very low priority for me right now (i don't even have a GPU with hardware RT) and even if i decide to implement it, i'll most likely use Vulkan-OpenGL interop just for raytracing than rewrite everything in Vulkan.
> Because Microsoft controls DirectX, they can look at what the GPU manufacturers are doing, draw up an API spec for the advanced stuff and the GPU manufacturers would hew to that spec.
Microsoft controlling DirectX is a negative in my view.
> OpenGL is designed by committee, a committee largely staffed by ancient CAD software vendors who insist on backward compatibility and it holds the API standard back.
That backwards compatibility is actually a fantastically great feature of OpenGL - it means code i wrote and worked years ago, still works, so i can focus on other things!
If i ever find part of the code doesn't work good enough (e.g. i need to do something in a different way) then i can only change that part - and it'll really be up to my decision to do so, not forced upon me.
> There's a janky extension system in place to allow GPU vendors to add functionality -- in proprietary, mutually incompatible ways that require the developer to write multiple code paths per unit of extension functionality.
Most useful stuff is in ARB and even when you write multiple code paths it is still easier and requires less code than having to code against some layer with different APIs at the back end for each OS or whatever.
> Use a game engine. It's got back ends for DX, Vulkan, Metal, even OpenGL (although that may change).
There is a chasmatic difference between a game engine and a graphics API (also the rendering code in most game engines is really only a small percentage of the entire engine even if it takes all the marketing focus). OpenGL is great in that it is high level enough to allow ease of use but not high level enough to force any framework-like functionality on you - you are free to design your renderer as you like.
Also because it is a standardized API there aren't random programmers waking up some morning and deciding that the design for their library/engine/framework/whatever could be done a bit """"better"""" and then going forward to break the API, making everyone who depends on it waste time getting up to date with their whims. `glClear` will always be there and do what it is supposed to do without someone thinking that it'll be a better idea to -e.g.- have separate `xxClearColor`, `xxClearDepth`, `xxClearStencil` in a vain and pointless refactor to avoid checking bit checks because that is slow (or whatever useless micromicrooptimization they come up with).
> If you must code to some 3D API, use DirectX.
DirectX is supported only on Windows (DXVK, etc are just hacks to play games whose developers do not want to make good Linux ports and cannot be relied on), controlled by Microsoft who likes to break the API in substantial ways every major version (older versions still work but you can't mix new and old functionality like OpenGL's extension system allows) and much harder to use compared to OpenGL.
