Carmack: Direct3D is now better than OpenGL

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.

But presumably it is at least part of the reason id have stuck with OpenGL and not switched to the 'better' API

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.

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.

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.

Unfortunately its name says "embedded", but it's very much the future of the standard.

http://www.gamedev.net/topic/504547-opengl30-i-mean-22/page_...

http://developers.slashdot.org/story/08/08/11/2135259/OpenGL...

One of the posts in the first link.

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

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

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

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.

[1] http://www.joystiq.com/2011/03/02/pc-gaming-sector-enjoyed-s... [2] http://www.gamasutra.com/view/news/33394/Interview_Frank_Gib...

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.

Both are good :)