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.
Call of Duty does not use OpenGL. Poor journalism.
It's so simple - take depends.exe and run it on the executable, or use procexp, then Ctrl+D and see what DLL's are being used.
Even more simpler - look at the Redist folder - it has DirectX in it.
I'm not really taking sides here - for my personal projects I use OpenGL, and find it easier to use (especially from Common Lisp, Lua, JavaScript), also it has structure that I like better.
Interesting that he says OpenGL has been more concerned with backwards compatibility than Microsoft has with Direct3D which is surprising considering Microsoft's normal compatibility fanaticism.
I think you are misinterpreting what he is saying. Direct3D is built on COM so the DirectX 1.0 COM interface still exists and code written against it should still work. However Microsoft has tried to make each version of the API internally consistent and as good as possible, so new versions of the API don't keep legacy junk sitting around.
OpenGL on the other hand has made sure that OpenGL1.0 code is still valid in current OpenGL(Pallet swapping FTW). Though I find it a bit odd that he is making that comment now. OpenGL 3.0(back in 2008) started the transition to a modern API. It deprecated the cruft and started building for the future. OpenGL 4.0 was released a year ago with all the deprecated stuff removed, and is now a nice clean API that is actually pretty close to DX.
This is api-level backwards compatibility for a library that is bundled with the games. Microsoft is fanatical about BC when the alternative is to break a piece of software. When the only people they're inconveniencing are developers, the philosophy changes. And rightly so, otherwise it's just that much harder to build new features.
Not really; Microsoft wants existing software to run on the next version of their OS, and that's still supported. The issue is of source compatibility, I think.
OpenGL did this via a fork, basically. The standard you really want to be looking at is OpenGL ES v2, which throws out almost all of the legacy stuff (begin/end, fixed function pipeline) in favor of a shader-only architecture which is much cleaner both for application and driver writers.
Unfortunately its name says "embedded", but it's very much the future of the standard.
>So let me get this straight... In order to allow what, a small handful of old CAD apps to compile against 3.0, they're willing to practically kill off all new applications developed against the API?
That makes sense. One customer a year ago is better than ten next week... [grin]
>Or maybe they've just realized that a) they've lost everything on Windows to DirectX so it doesn't really matter what they do there, and b) since they don't have a single competing API on other platforms, they don't actually need to make an effort there either.
>End result, they can screw over developers as much as they like, and it won't actually hurt them. Windows developers wouldn't have used OGL in the first place, and everyone else will keep using them because there are no alternatives.
There are some interesting things happening in the graphics space, driven mainly by low-power/mobile device proliferation. It would be a good time to invent something that changes how real-time rendering happens altogether.
5-10 years ago this headline would have been more likely to appear on April 1, as John Carmack used to be a member of the OpenGL architecture review board.
In January 2007, John Carmack said that "…DX9 is really quite a good API level. Even with the D3D side of things, where I know I have a long history of people thinking I'm antagonistic against it. Microsoft has done a very, very good job of sensibly evolving it at each step—they're not worried about breaking backwards compatibility—and it's a pretty clean API. I especially like the work I'm doing on the 360, and it's probably the best graphics API as far as a sensibly designed thing that I've worked with."
Exactly, what I was trying to get at is OpenGL ES is winning on mobile. DirectX really has no answer and even Windows Devices right now are pretty much XNA/.NET/Silverlight locked as you say no native. Android has the NDK now (year or so ago) because iOS SDK was native and allowed for the performance needed.
If Carmack only built in DirectX which is so much farther ahead, he wouldn't be on mobile. OpenGL is much different after 2006 when Khronos took over.
Multi-platform support is key - for example, where's Direct3D for Android and iOS? All the viable gaming platforms, other than the Xbox 360, are running some OpenGL variant.
PC gaming is dying the slow death of piracy and activation - while games can perform better (aren't held back by 5 year old console/mobile hardware), and have better input (keyboard + mouse for FPS), the game vendors can't make as much money on them.
That said, Microsoft did push the envelope on this - they weren't held back by the committee model like OpenGL is.
> PC gaming is dying the slow death of piracy and activation
No. No it is not, will everyone please stop spreading this unfounded misinformation.
The PC market is in rude health and growing. Last year total PC gaming revenues were estimated at over $16 billion, growing 20% year-on-year[1]. Growing the market 20% in one year is generally not described as 'dying [a] slow death'.
Lots of developers and publishers are seeing increased opportunity in the market, such as EA (Electronic Arts, the 2nd biggest games publisher) which has suggested the PC may soon become it's primary platform[2].
I think it's safe to say we should hold off on the obituaries for now.
Indeed. http://www.gamesetwatch.com/newzoo_2010spend.jpg shows that traditional non-MMO PC gaming is a larger portion of the market than most consoles, even in the US. Plus with digital distribution publishers get 70-100% of the money customers spend, as opposed to retail's ~30%, so you need to sell half to a third as much as on consoles to make just as much money.
All the viable gaming platforms, other than the Xbox 360, are running some OpenGL variant.
That's pushing it a little. Maybe you mean "viable for low-budget, independent developers" (no expensive devkit needed)? It's not that widespread on consoles: Nintendo still seem to be doing well, and none of their platforms support anything close to OpenGL. I'm aware that there is an OpenGL ES implementation for the PS3, but I'd be surprised if that was the only way or even the preferred method of talking to the graphics chip. In my experience, game console graphics programming is usually super low level, with the "API" consisting of a bunch of inline C functions and enum constants for twiddling GPU hardware registers, filling DMA buffers and handling interrupts.
Graphics APIs serve 2 purposes:
1. hardware and OS independence (consistent API for the same OS running on different GPU hardware, or for porting software between OSes)
2. sandboxing apps to prevent direct hardware access. The latter is useful for any multitasking platform, whether it's explicitly multi-tasking or just to shield the foreground app from accessing stuff running in the background, like on older iOS versions.
If you care about neither, or the latter is taken care of in hardware (IOMMU), then raw access to the GPU lets you do stuff that's way cooler than you could do with a driver and an API (though it's usually more work).
Well sure, if you're a AAA studio developing bleeding-edge Xbox360/PS3/PC games that squeeze every drop of performance from the GPU (Carmack's area of expertise), your technical choices are going to be very different from those who are developing less graphically-intensive games for iOS/Android/PC/Mac.
I suspect the latter group is better represented on HN. And for those, OpenGL ES is almost certainly the best choice.
In case it's not clear: I wasn't passing judgement, merely explaining the situation and weighing up the advantages of the various approaches. For iOS, Android and Mac, OpenGL is pretty much the only choice, and sticking to the subset that is OpenGL ES even on the Mac is sensible if there's a chance you might want to port. That said, if your needs aren't such that you need close-to-the-metal access to the hardware, you may well be best off using one of the many inexpensive third-party engines altogether.
I would think that the PS3 supports more than just ES, as Unigine has been offering their engine for use on the console, and their benchmarks using said engine use the latest OpenGL 4 features like HW tesselation (http://unigine.com).
I don't know what the story is exactly (I quit my job at a major UK developer shortly before I was supposed to start working on a PS3 project) but there are some details here: http://en.wikipedia.org/wiki/PSGL
Since RSX is rumoured to not be that powerful, I suspect Unigine might be doing the tesselation on the Cell's SPUs.
Even with OpenGL you don't get multi-platform for free. Neither with D3D (PC and XBOX)
There are more important things to consider:
- Image compression supported (DXT vs. PVRTC vs. others)
- Type of rendering buffers supported and precision (stencil, z-buffer, etc)
- Features of the latter - can you do some prepass to skip pixel shaders?
- Normal map encoding and compression
- Primitive buffering (batching) - static, dynamic, or low-level if the platform allows it
- Minimizing state changes
- Organizing mesh data for most optimum cache
- Hardware level queries - "Did last primitive actually drawn something on the screen?"
So what the drawing api is of little importance for big AAA games. Data organization and features (what actually is supported on the HW, and which rendering paths are fast) is more important.
Now for CAD/3D Designer apps - you have more dynamic data - your meshes change too much, textures. You need very good looking wireframe antialiasing, etc.
For games - almost everything is precooked - starting from global illumination, meshes that have been cache optimized and had vertices welded where possible. Level maps optimized so that they draw faster, and batched so that with few draw calls you draw the whole level, etc.
My opinion is that OpenGL is really suitable for the latter, but it's also suitable for the former. Though D3D by not keeping much backward API compability can talk to the hardware in more straightforward talk, hence the API design:
OpenGL - functions with general types, not much if not at all structures. Easily to serialize (protocolize).
Direct3D - functions with very specific goals, using structures more or less tied to the hardware, or the operating system, hence less portability.
For example I can't see D3D as an API taking off the way webGL is doing, simply because it's hard to map it's API to a scripting language, while OpenGL can.
