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.
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. 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.
>> I find it odd that there was no mention of working on multiple platforms as an advantage of using OpenGL.
> 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.)
In addition to everything you said about the rise of mobile and casual gaming, there's also the rise of Mac OS based machines and also the increasing cost of developing high-end games.
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.
The comment talked a bit about why they chose to stick with OpenGL, but mentions only "inertia". I suspect "we can support Linux and Mac, maybe some mobile platforms too" might also have a bit to do with it.
It's a bit philosophical too. D3D is an abstraction of graphics hardware with enough high-level constructs to make it useful to real programmers. OGL is an abstraction of 3D principles, with enough low-level constructs to make it perform on real hardware. You can't "unplumb" that overnight; it's how you think.
Yes, Java definitely has an advantage over C# because it's multi-platform. Granted C# really has done a great job of adding nice features that I wish were in Java...
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.
Mono does give you the ability to run C# code everywhere. So, correct, it's not the language itself that's preventing you to write C# once, run everywhere. Perhaps you understood where I was going in the first place?
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.
I don't understand where you're going, no. I write C# on Windows and deploy to Linux and Mac pretty regularly. I know someone who writes C# on Windows and deploys to Arduino.
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 mostly do web & server-side development so I'm not sure my opinion is going to be terribly valuable there. However, I think many people use GTK# because it's the most mature.
I think it's also that more people trust the (openjdk/sunjdk) as a high performance vm with tons of money spent on developing an excellent gc and jit with a ton compared to mono. Although on the other hand its true that many people use an interpreter/vm like ruby 1.8 without much trouble.
