I find it odd that there was no mention of working on multiple platforms as an advantage of using OpenGL. I've bought a game or three I wouldn't have otherwise because they offered a Linux version, and I suspect I'm not the only one.
When it comes to a AAA game the big three sellers are Xbox, PS3, and PC, in roughly that order. Two of those use a D3D API that's very similar and PS3 uses something called GCM[1]. All of these have vendor support and tools that leave OpenGL, on any platform, in the dust. For example: in PIX (D3D Debugger) you can actually click on a wrong-looking pixel and see everything that contributed to its rendering. It's freaking amazing.
Developers who are investing millions of dollars in making a game will generally be picking at least two of these platforms, usually Xbox & PS3, or Xbox and PC. Even if the game was PC only, or PC & PS3, picking OpenGL means you're leaving a lot of productivity on the table over the course of your development lifetime.
But here's another reason - if you later decide that you want to release an iPad/iPhone/Android version of your game, or build something for these platforms using your engine, then porting the rendering code that draws meshes or sprites[2] is going to be one of the easier parts of that process.
The hard part is figuring out how to reimplement features that lack hardware support or performance on the new platform. Even if your original engine was built using OpenGL, the chances are you'll be writing whole new code paths for something like shadowing anyway. The "write once, run anywhere" theory behind OpenGL is largely a myth when it comes to shipping anything of complexity on two different platforms.
[1] PS3 does/did have something called PSGL that had an OGL-like API, but it's performance is poor and no one uses it. Back in 2006 there was even something of a developer revolt when it looked like this would be the only available API. Wii's graphics library, GX, is similar-ish to OpenGL but with lots of extras. Ditto DS/3DS. PSP and NGP use custom APIs.
[2] If you've put any degree of thought into your engine, all of this code will be in a separate lower level driver-like layer that can be reimplemented for new platforms as needed without changing something like, for example, the code that draws your HUD.
> Because it's really not much of an advantage. Seriously.
> When it comes to a AAA game the big three sellers are Xbox, PS3, and PC, in roughly that order.
That is true. But, AAA games are not all of gaming. In fact, they are decreasing in importance - look at the rise of the Wii and Zynga as just two big examples.
Gaming is growing, and moving from hardcore gamers with AAA games to more casual gamers that use a greater variety of devices. Mobile phones and tablets in particular are becoming very important, as is the web.
DirectX is simply not relevant to any major phone or tablet platform, nor is it relevant to the web. iOS and Android use OpenGL, and the web uses WebGL (which is basically OpenGL ES in JavaScript).
OpenGL, by simply being everywhere that matters, will win the fight.
(Of course major game engines use abstraction layers anyhow - no one chooses just DirectX or just OpenGL.)
IMO all of these factors points seem to point towards developers making choices in the future based less on high-end API features and more on cross-platform support...
AFAIK lots of Mac games use some kind of D3D-OpenGL translation layer (of course this won't help you with D3D features that don't exist in OpenGL). OpenGL still seems to be the API of choice for mobile and Web use, though.
But presumably it is at least part of the reason id have stuck with OpenGL and not switched to the 'better' API
This kind of story seems to happen when committees are involved, and there is an overarching need for backwards compatibility. Closures in Java arrive in 2012. 2013 at the latest.
Anyway, people choose Java because they can write once and deploy everywhere. If you write in the C# .Net ecosystem on Windows, it won't run everywhere, which is fine if Windows is your only target.
C# seems to be roughly as portable as Java does to me these days. I'm sure I could be wrong, which is why I'm asking which places you can run Java that you can't run C#. Yes, you can write non-portable C# code, but you can write non-portable code in every language.
I routinely run my C#-written utilities on Solaris, of all things.