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.
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.
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.
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."
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.
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).
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.
[+] [-] Zak|15 years ago|reply
[+] [-] ajg1977|15 years ago|reply
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.
[+] [-] wmf|15 years ago|reply
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.
[+] [-] aquark|15 years ago|reply
But presumably it is at least part of the reason id have stuck with OpenGL and not switched to the 'better' API
[+] [-] melling|15 years ago|reply
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.
[+] [-] malkia|15 years ago|reply
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.
[+] [-] zokier|15 years ago|reply
[+] [-] bhrgunatha|15 years ago|reply
[+] [-] stonemetal|15 years ago|reply
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.
[+] [-] awj|15 years ago|reply
[+] [-] timthorn|15 years ago|reply
[+] [-] ajross|15 years ago|reply
Unfortunately its name says "embedded", but it's very much the future of the standard.
[+] [-] th0ma5|15 years ago|reply
[+] [-] recoiledsnake|15 years ago|reply
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.
[+] [-] rch|15 years ago|reply
[+] [-] jessedhillon|15 years ago|reply
[+] [-] PassTheAmmo|15 years ago|reply
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."
[+] [-] drawkbox|15 years ago|reply
Maybe technologically DirectX is ahead but platform support and inclusion is the reason it is not winning on mobile.
Also WebGL is coming and OpenGL ES 2.0 for mobile and web will be a very similar platform.
Where is DirectX for the web and mobile in that aspect? And why doesn't Carmack try to port Rage to WIndows Phone...
[+] [-] Strom|15 years ago|reply
[+] [-] andrewf|15 years ago|reply
[+] [-] alttab|15 years ago|reply
[+] [-] rbanffy|15 years ago|reply
[+] [-] zdw|15 years ago|reply
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.
[+] [-] NickPollard|15 years ago|reply
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...
[+] [-] pmjordan|15 years ago|reply
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).
[+] [-] malkia|15 years ago|reply
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 :)