4 ms·

Alternative take: An Open API is good, but Microsoft and Nvidia are too powerful to allow it http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-

Alternative take: An Open API is good, but Microsoft and Nvidia are too powerful to allow it http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-DirectX http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-an...

m12k 6y ago
I'm not much of a graphics programmer, so take this with a grain of salt, but from talking to people who are, the impression I've gotten is that OpenGL is stuck in this weird middle state where it still has two ways of doing things, a simple and easy, but inefficient way where you specify everything from scratch each frame, and one where you use more persistent state like vertex buffer objects to minimize copying and speed things up, but the latter has a cumbersome bolted-on-top API. By comparison DirectX only supports the latter, but was from the start designed with a nicer API to deal with this persistent state, so engine programmers tend to prefer it. And rumor has it that it was the CAD companies that were preventing a modernization of the OpenGL API to properly compete with the ease-of-use of DirectX. So this wasn't just a fight of open vs proprietary, it was also a fight of design-by-committee vs single coherent architectural vision.
- glowcoil 6y ago
  This isn't really accurate; the immediate-mode approach you're talking about was deprecated in OpenGL 3.0 and was never supported in OpenGL ES, and in fact, Direct3D started out with an immediate-mode API just like OpenGL before moving to retained vertex buffers.
- skohan 6y ago
  As someone who spent quite a bit of time with OpenGL, this criticism never really scanned with me. Yes there were multiple ways to do things, but it was fairly easy to understand what the modern parts of the API were and just use that subset. If you run through any modern OpenGL tutorial it will explain this very concisely, and I never had an issue being unsure which parts of the API to use. That said, Vulkan really does solve all of the real pain-points which existed with OpenGL. It’s very well documented and nice to use, and I really don’t understand why anyone would choose a proprietary api over it.

m12k 6y ago

I'm not much of a graphics programmer, so take this with a grain of salt, but from talking to people who are, the impression I've gotten is that OpenGL is stuck in this weird middle state where it still has two ways of doing things, a simple and easy, but inefficient way where you specify everything from scratch each frame, and one where you use more persistent state like vertex buffer objects to minimize copying and speed things up, but the latter has a cumbersome bolted-on-top API. By comparison DirectX only supports the latter, but was from the start designed with a nicer API to deal with this persistent state, so engine programmers tend to prefer it. And rumor has it that it was the CAD companies that were preventing a modernization of the OpenGL API to properly compete with the ease-of-use of DirectX. So this wasn't just a fight of open vs proprietary, it was also a fight of design-by-committee vs single coherent architectural vision.

glowcoil 6y ago
This isn't really accurate; the immediate-mode approach you're talking about was deprecated in OpenGL 3.0 and was never supported in OpenGL ES, and in fact, Direct3D started out with an immediate-mode API just like OpenGL before moving to retained vertex buffers.
skohan 6y ago
As someone who spent quite a bit of time with OpenGL, this criticism never really scanned with me. Yes there were multiple ways to do things, but it was fairly easy to understand what the modern parts of the API were and just use that subset. If you run through any modern OpenGL tutorial it will explain this very concisely, and I never had an issue being unsure which parts of the API to use. That said, Vulkan really does solve all of the real pain-points which existed with OpenGL. It’s very well documented and nice to use, and I really don’t understand why anyone would choose a proprietary api over it.