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.
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.