5 ms·

Having used both extensively, I am very disappointed with both systems. It is almost as if they do not care about developers any more. OpenGL has little/no in

Having used both extensively, I am very disappointed with both systems. It is almost as if they do not care about developers any more. OpenGL has little/no incentive to improve itself because it is not tied closely to any single commercial product, and DirectX used to be very well developed, but it seems Microsoft borderline lost interest in it (the leap from 9 to 10 to 10.1 to 11 happened fast, since then it has been fairly stagnant). For all intents and purposes, the average developer is still stuck developing at the DX9 level API to maximize compatibility. OpenGL could be great, but some central party needs to take ownership of it (without putting up a walled garden like Microsoft). As it is now, OpenGL is facing the same problems as HTML5 - a bunch of committees that are slow to make decisions and don't really care that much about the product. Combine that with the fact that we only have two major card manufacturers now (Nvidia and ATI/AMD), and there is just not enough competition to drive the space effectively. Both products are usable, I am just annoyed by their borderline-stagnation.

dualogy 14y ago
I disagree, I think GL has been developing quite nicely over the last 2 or so years, driven by lots of innovation coming from Nvidia and ATI, and a close dialog with graphics developers worldwide. GL is seen as a "crufty", non-OO C-style API but that's actually pretty cool in that it gives you very direct GPU access and gently forces you to think more in a way that matches how current-gen GPUs actually work. I wouldn't any magical abstractions over it. The core profile is great because all the outdated legacy stuff is no longer legal in it, giving you a modern, direct-hardware-acess graphics API with absolutely zero overhead. Driver support keeps getting better, even Intel has entered into GL 4.x land by now. Proprietary Linux drivers and their GL 4.x support are really solid and better than ever. All that remains is for Apple to get up to speed, GL is still at 2.1 or 3.2 depending on your OS X version.
- nglevin 14y ago
  There is some support for GLSL 3.3, 4.0 and 4.1 in OS X Mountain Lion; http://renderingpipeline.com/2012/11/first-hints-of-opengl-4-on-macos-x/ http://renderingpipeline.com/2012/11/first-hints-of-opengl-4... GLSL 3.3 was present but hilariously broken in Lion, if you explicitly requested it in your shaders. Hopefully things will improve for Mac OS X 10.9.
  - dualogy 14y ago
    Yeah I've seen those, but 2.1 comp or 3.2 core is what you can "count on officially" as of now. I'd rather have code branches just depending on GL_VERSION, and none ever depending on extensions... if extensions make it in the next core profile, they can make it into my code. Then, if that version shows up on OSX 5 years later, great for those Macster users, they're into retro stuff anyway ;)
- gavanwoolery 14y ago
  Yeah that is a good point - improvement has not been entirely lacking. But I would still like to see a bit more innovation. For example, one thing that is kind of ridiculous to me is the continued use of multiple render targets. We have long gone past the use of textures for their original purpose, now they are basically general purpose data banks and should be treated as such. I would rather write to one texture with an arbitrary number of channels (even if it occurs differently inside GPU memory) -- and include the depth buffer as one of these channels. Also I would love to see GPU memory get bumped up - we have more or less been resting in the 1-2 GB zone for the past several years thanks to consoles (not an API issue, obviously).

dualogy 14y ago

I disagree, I think GL has been developing quite nicely over the last 2 or so years, driven by lots of innovation coming from Nvidia and ATI, and a close dialog with graphics developers worldwide. GL is seen as a "crufty", non-OO C-style API but that's actually pretty cool in that it gives you very direct GPU access and gently forces you to think more in a way that matches how current-gen GPUs actually work. I wouldn't any magical abstractions over it. The core profile is great because all the outdated legacy stuff is no longer legal in it, giving you a modern, direct-hardware-acess graphics API with absolutely zero overhead. Driver support keeps getting better, even Intel has entered into GL 4.x land by now. Proprietary Linux drivers and their GL 4.x support are really solid and better than ever. All that remains is for Apple to get up to speed, GL is still at 2.1 or 3.2 depending on your OS X version.

nglevin 14y ago
There is some support for GLSL 3.3, 4.0 and 4.1 in OS X Mountain Lion; http://renderingpipeline.com/2012/11/first-hints-of-opengl-4-on-macos-x/ http://renderingpipeline.com/2012/11/first-hints-of-opengl-4... GLSL 3.3 was present but hilariously broken in Lion, if you explicitly requested it in your shaders. Hopefully things will improve for Mac OS X 10.9.
- dualogy 14y ago
  Yeah I've seen those, but 2.1 comp or 3.2 core is what you can "count on officially" as of now. I'd rather have code branches just depending on GL_VERSION, and none ever depending on extensions... if extensions make it in the next core profile, they can make it into my code. Then, if that version shows up on OSX 5 years later, great for those Macster users, they're into retro stuff anyway ;)
gavanwoolery 14y ago
Yeah that is a good point - improvement has not been entirely lacking. But I would still like to see a bit more innovation. For example, one thing that is kind of ridiculous to me is the continued use of multiple render targets. We have long gone past the use of textures for their original purpose, now they are basically general purpose data banks and should be treated as such. I would rather write to one texture with an arbitrary number of channels (even if it occurs differently inside GPU memory) -- and include the depth buffer as one of these channels. Also I would love to see GPU memory get bumped up - we have more or less been resting in the 1-2 GB zone for the past several years thanks to consoles (not an API issue, obviously).