This post doesn't make any sense. The people who define the OpenGL spec include delegates from ATI, Creative Labs, Intel, and Nvidia. Khronos doesn't go out and engage the vendors? They're a consortium of the vendors you claim they don't engage.
The reason for the core OpenGL spec lagging with consumer level graphics stuff is largely due to its incredible breadth of applications and target platforms. With OpenGL 3.0 there was a lot of contention between the people who wanted to turn it into a streamlined real time gaming API, and the people who used it for other industries where a lot of features not supported on gaming hardware were still useful for non-gaming applications. It started with a very ambitious revamping proposal, followed by months of (rather aggrivating) total silence, then culminated with the deprecation model that's currently in place.
OpenGL's problems don't have anything to do with Direct3D being more in the loop than they are about new hardware developments. It's inherently more challenging to keep pace and be flexible because they're maintaining a broad spec used by a lot of different companies in a lot of different specialized fields. As far as feature deployment is concerned, on more than one occasion Nvidia has had drivers out on the same day Khronos releases a new spec. Current desktop OpenGL is quite a nice, modern API that's suitable for cutting edge game development. The new deprecation model allows driver authors to create profiles optimized for specific classes of applications (of which there are many where OpenGL is useful). On Windows, libraries like GLEW make Microsoft's decision to not move the ABI forward a non-issue. OpenGL ES is very much a modern API that's useful across a wide variety of in-demand mobile platforms. The way modern GL handles things like VBOs and render to texture are at least as good as Direct3D.
I'm not advocating the use of OpenGL over D3D or vice versa. Right now I primarily do Android and web development stuff, so I'm kind of saturated in OpenGL-centric environments. I just felt the need to respond to that weird claim that Khronos is disengaged from hardware vendors. Khronos largely ARE hardware vendors.
Sincerely,
MS Fanboy with an Xbox 360, XNA Creators Club subscription, and a deep love for Visual Studio and C# who uses Bing search (and doesn't think IE9 is absolutely terrible)
I hate to gripe, but there are a few glaring misconceptions that need to be addressed in your post. Mainly this claim that DirectX/Direct3D is "pointing and clicking in Visual Studio." You're probably thinking more along the lines of XNA, but core Direct3D is a pretty basic interface to the graphics hardware (you're dealing with vertex buffers, texture objects, vertex/pixel shaders and their associated inputs, and a number of state parameters). Functionality wise it offers essentially what OpenGL does, except wrapped up in a platform-specific COM interface. There is a higher level library called D3DX that adds some helper functions for loading textures and meshes and doing vector and matrix math, but even that's quite a ways from the "pointing and clicking in Visual Studio" you mentioned.
DirectX isn't "easier" than OpenGL/OpenAL (in fact, OpenAL is higher level than DirectSound or XAudio, if you've ever used any of those APIs). The extra price of OpenGL comes not from "the fact they are intended for real developers" (whatever that means), but rather from the fact that it's not exactly the cleanest API at the moment (but that will change in a few months when OpenGL 3.0 finally hits). In combing through this thread I'm surprised I haven't seen mentioned that one big reason Direct3D took off over OpenGL on Windows is because OpenGL is notoriously difficult to write stable, performant drivers for. An article in issue #2 of the OpenGL newsletter mentioned how the old object model caused unnecessary driver overhead, for instance: http://www.opengl.org/pipeline/article/vol002_3/
Back in the late 90's when all this stuff was taking off, major games like Half-Life, Quake 2, and Unreal had several graphics renderers encapsulated in DLLs. Half-Life had software, OpenGL, and Direct3D. Quake 2 had software, OpenGL, and I think PowerVR or something. Unreal had a heck of a lot of different renderers, I know software, D3D, Glide, and OpenGL were among them. They did this because driver performance and compatibility was such a big issue back then, by writing to more than one API they could cover all the bases (card X doesn't run GL well but does run D3D well? Then we support that scenario. Card Y runs D3D poorly but does GL well? We support that, too). At the end of the day, the major graphics vendors ended up putting out really excellent D3D drivers and that helped the API out significantly. D3D was the only hardware-agnostic solution back then aside from OpenGL (ATI wasn't implementing Glide), and the API mapped to the general hardware case well enough that it was relatively easy for most vendors to write good drivers for.
Like pretty much everyone else who isn't a Microsoft employee, I do wish Microsoft would have adopted OpenGL as the sole hardware graphics standard instead of running off and creating their own thing and creating yet another obstacle to porting games over to different platforms (and to be clear, there are MANY more issues to porting games to different platforms than I/O APIs, for some reason I'll never understand that point is lost on a lot of people), but painting game developers who use DirectX as corporate Microsoft shills isn't the most honest or productive characterization of why things are the way they are. What is productive is looking at the technical flaws present in OpenGL and rectifying them, which is something the Khronos ARB Working Group has done an excellent job of.
As far as id is concerned, Carmack is using the Direct3D-only Xbox 360 as his benchmark development platform at the moment (you can go back to his Quakecon 2005 speech for a reference on that). That doesn't mean he's turned into a D3D fanboy, the Windows version of Rage is still going to be OpenGL. What it does mean is, these days he's probably more concerned with things like efficient multicore utilization, robust and productive content developer toolsets, and having a nice stable platform with excellent developer support as a testbed (something Mic
Slashdot Mirror
This post doesn't make any sense. The people who define the OpenGL spec include delegates from ATI, Creative Labs, Intel, and Nvidia. Khronos doesn't go out and engage the vendors? They're a consortium of the vendors you claim they don't engage.
The reason for the core OpenGL spec lagging with consumer level graphics stuff is largely due to its incredible breadth of applications and target platforms. With OpenGL 3.0 there was a lot of contention between the people who wanted to turn it into a streamlined real time gaming API, and the people who used it for other industries where a lot of features not supported on gaming hardware were still useful for non-gaming applications. It started with a very ambitious revamping proposal, followed by months of (rather aggrivating) total silence, then culminated with the deprecation model that's currently in place.
OpenGL's problems don't have anything to do with Direct3D being more in the loop than they are about new hardware developments. It's inherently more challenging to keep pace and be flexible because they're maintaining a broad spec used by a lot of different companies in a lot of different specialized fields. As far as feature deployment is concerned, on more than one occasion Nvidia has had drivers out on the same day Khronos releases a new spec. Current desktop OpenGL is quite a nice, modern API that's suitable for cutting edge game development. The new deprecation model allows driver authors to create profiles optimized for specific classes of applications (of which there are many where OpenGL is useful). On Windows, libraries like GLEW make Microsoft's decision to not move the ABI forward a non-issue. OpenGL ES is very much a modern API that's useful across a wide variety of in-demand mobile platforms. The way modern GL handles things like VBOs and render to texture are at least as good as Direct3D.
I'm not advocating the use of OpenGL over D3D or vice versa. Right now I primarily do Android and web development stuff, so I'm kind of saturated in OpenGL-centric environments. I just felt the need to respond to that weird claim that Khronos is disengaged from hardware vendors. Khronos largely ARE hardware vendors.
Sincerely,
MS Fanboy with an Xbox 360, XNA Creators Club subscription, and a deep love for Visual Studio and C# who uses Bing search (and doesn't think IE9 is absolutely terrible)
or best: http://www.youtube.com/watch?v=hkDD03yeLnU
Fabless? Or Fabulous?
I hate to gripe, but there are a few glaring misconceptions that need to be addressed in your post. Mainly this claim that DirectX/Direct3D is "pointing and clicking in Visual Studio." You're probably thinking more along the lines of XNA, but core Direct3D is a pretty basic interface to the graphics hardware (you're dealing with vertex buffers, texture objects, vertex/pixel shaders and their associated inputs, and a number of state parameters). Functionality wise it offers essentially what OpenGL does, except wrapped up in a platform-specific COM interface. There is a higher level library called D3DX that adds some helper functions for loading textures and meshes and doing vector and matrix math, but even that's quite a ways from the "pointing and clicking in Visual Studio" you mentioned.
DirectX isn't "easier" than OpenGL/OpenAL (in fact, OpenAL is higher level than DirectSound or XAudio, if you've ever used any of those APIs). The extra price of OpenGL comes not from "the fact they are intended for real developers" (whatever that means), but rather from the fact that it's not exactly the cleanest API at the moment (but that will change in a few months when OpenGL 3.0 finally hits). In combing through this thread I'm surprised I haven't seen mentioned that one big reason Direct3D took off over OpenGL on Windows is because OpenGL is notoriously difficult to write stable, performant drivers for. An article in issue #2 of the OpenGL newsletter mentioned how the old object model caused unnecessary driver overhead, for instance: http://www.opengl.org/pipeline/article/vol002_3/
Back in the late 90's when all this stuff was taking off, major games like Half-Life, Quake 2, and Unreal had several graphics renderers encapsulated in DLLs. Half-Life had software, OpenGL, and Direct3D. Quake 2 had software, OpenGL, and I think PowerVR or something. Unreal had a heck of a lot of different renderers, I know software, D3D, Glide, and OpenGL were among them. They did this because driver performance and compatibility was such a big issue back then, by writing to more than one API they could cover all the bases (card X doesn't run GL well but does run D3D well? Then we support that scenario. Card Y runs D3D poorly but does GL well? We support that, too). At the end of the day, the major graphics vendors ended up putting out really excellent D3D drivers and that helped the API out significantly. D3D was the only hardware-agnostic solution back then aside from OpenGL (ATI wasn't implementing Glide), and the API mapped to the general hardware case well enough that it was relatively easy for most vendors to write good drivers for.
Like pretty much everyone else who isn't a Microsoft employee, I do wish Microsoft would have adopted OpenGL as the sole hardware graphics standard instead of running off and creating their own thing and creating yet another obstacle to porting games over to different platforms (and to be clear, there are MANY more issues to porting games to different platforms than I/O APIs, for some reason I'll never understand that point is lost on a lot of people), but painting game developers who use DirectX as corporate Microsoft shills isn't the most honest or productive characterization of why things are the way they are. What is productive is looking at the technical flaws present in OpenGL and rectifying them, which is something the Khronos ARB Working Group has done an excellent job of.
As far as id is concerned, Carmack is using the Direct3D-only Xbox 360 as his benchmark development platform at the moment (you can go back to his Quakecon 2005 speech for a reference on that). That doesn't mean he's turned into a D3D fanboy, the Windows version of Rage is still going to be OpenGL. What it does mean is, these days he's probably more concerned with things like efficient multicore utilization, robust and productive content developer toolsets, and having a nice stable platform with excellent developer support as a testbed (something Mic