Is Doom 3's release going to change the OpenGL community?
- Thread starter micron
- Start date
What matters currently I would say it helps ensure it still exists against Microsoft. And I don't know of a school that encourages of programming in DirectX instead of OpenGL. At least at my school the idea of DirectX isn't an option, as long as there is Linux with no DirectX there will be OpenGL.
I don't think Doom 3 overall will change the community much though. For professional apps you will see in general the use of OpenGL and for games a dominance in DirectX.
I don't think Doom 3 overall will change the community much though. For professional apps you will see in general the use of OpenGL and for games a dominance in DirectX.
I think it's simply that DirectX advances so much faster that has made it the dominent force in the market right now. The second OpenGL 2.0 is ratified, I'd be surprised if we don't start seeing more OpenGL titles again... hell, the Doom 3 engine itself will probably kick start that.
Doom 3 engine is basically "DirectX 7 / DirectX 8 " techlevel engine, so what OGL really needs (gamewise that is...) is a kickass engine based on heavily to the new 2.0 standard. More complex shaders and all that.
You can go to the http://www.eurogamer.net and check out the Unreal 3 engine screenshots, some of the that sm3 level stuff just blows Doom 3 away.
You can go to the http://www.eurogamer.net and check out the Unreal 3 engine screenshots, some of the that sm3 level stuff just blows Doom 3 away.
Doomtrooper
Veteran
Don't forget Doom 3 has been ported to X-box or DirectX.
He's just using at as an illustration of the types of graphics that can be enabled on modern pipelines, couldn't really have been achieved with D3 because it was OpenGL and the capabilities of it were in a mess.
Look at the number of different code paths there are for the engine: at least two "OpenGL" paths, 3 vendor specific paths and one test OpenGL2.0 path - six different egine paths have been coded; had this been DX probably 3 of those could have been removed. Had the ARB got its ass in gear probably a two or three of those paths would be needless for modern hardware under OpenGl 2.0.
The ARB has the capabilitiy of moving on OpenGL quite considerably with OpenGL2.0 but they've been sitting on their hands over its release because of the way the ARB is structured - differing groups with differing competetive interests. I really hope that OGL2.0 does come out this year as it is supposed to and there are no further delays.
Look at the number of different code paths there are for the engine: at least two "OpenGL" paths, 3 vendor specific paths and one test OpenGL2.0 path - six different egine paths have been coded; had this been DX probably 3 of those could have been removed. Had the ARB got its ass in gear probably a two or three of those paths would be needless for modern hardware under OpenGl 2.0.
The ARB has the capabilitiy of moving on OpenGL quite considerably with OpenGL2.0 but they've been sitting on their hands over its release because of the way the ARB is structured - differing groups with differing competetive interests. I really hope that OGL2.0 does come out this year as it is supposed to and there are no further delays.
D3 only has one default path (ARB2) now, the ARB path is no longer supported. Also, Robert Duffy confirmed that there are shaders/effects you can only get on the ARB2 path (like heat shimmers, etc.). If ppl still want to label it as a Dx7/8 game fine, but I don't know how much more id can say that will convince them otherwise.
Regarding Carmack and Dx. All he said was that the next engine after DOOM would use a high-level shading language.
Regarding Carmack and Dx. All he said was that the next engine after DOOM would use a high-level shading language.
AndrewM said:
Well, part of the point of 2.0 was to remove some of the legacy elements from the core. However, if it is just a marketting exercise they need to do it to give some indications that they can, as a group, progress instead of just going down the same tired dead path that they are right now.
Mordenkainen said:
The point being that this is still work that has been done - its even worse that its now wasted work.
Not that much knowledge of 3D APIs around here IMO 
Using OpenGL you have the ARB_fp/ARB_vp extensions which cover the ASM-like interface to some hardware, it's like the DirectX Graphics vertex/fragment shader.
There's also ARB_shader_object along with ARB_vs/ARB_fs extensions, which is GLSlang, a high level shading language, conceptually similar to DirectX Graphics HLSL.
Then you have the old stuff like DOT3 and all extensions, just like in DirectX Graphics.
To adress different hardware segment no matter the API, you'll have to code different code paths, that's something you just can't escape right now, in the future, hopefully, using high level shader languages, this should be solved.
Now what you CAN DO in OpenGL and NOT in DirectX Graphics, is access the hardware 'to the metal' using vendor specific extensions to get the most out of it.
This is OPTIONAL, but you CAN, which is a big plus for OpenGL compared to DirectGraphics.
Basically DirectX Graphicsis a subset of OpenGL, feature wise.
As for OpenGL2.0 it's supposed to be a major API revision (hence the name), which gets ride of legacy stuff to have a cleaner and simpler interface, it will be no different too DirectX revisions, except you don't have to change much/most of your code to get advantage of it.
(DirectX Graphics, formerly Direct3D, has changed its interface extensively between two version in the past, meaning that you had to rewrite most of the engine to be able to access the new hot features)
Using OpenGL you have the ARB_fp/ARB_vp extensions which cover the ASM-like interface to some hardware, it's like the DirectX Graphics vertex/fragment shader.
There's also ARB_shader_object along with ARB_vs/ARB_fs extensions, which is GLSlang, a high level shading language, conceptually similar to DirectX Graphics HLSL.
Then you have the old stuff like DOT3 and all extensions, just like in DirectX Graphics.
To adress different hardware segment no matter the API, you'll have to code different code paths, that's something you just can't escape right now, in the future, hopefully, using high level shader languages, this should be solved.
Now what you CAN DO in OpenGL and NOT in DirectX Graphics, is access the hardware 'to the metal' using vendor specific extensions to get the most out of it.
This is OPTIONAL, but you CAN, which is a big plus for OpenGL compared to DirectGraphics.
Basically DirectX Graphicsis a subset of OpenGL, feature wise.
As for OpenGL2.0 it's supposed to be a major API revision (hence the name), which gets ride of legacy stuff to have a cleaner and simpler interface, it will be no different too DirectX revisions, except you don't have to change much/most of your code to get advantage of it.
(DirectX Graphics, formerly Direct3D, has changed its interface extensively between two version in the past, meaning that you had to rewrite most of the engine to be able to access the new hot features)
Ingenu, the problem is that the ARB can just be too slow to react in making changes to the core - while the ARB fragment and vertex shader extensions are now available, how long did it take the ARB to settle on them? IIRC the vertex program extension was available for some time before the arb finally hammered out a version of the fragment program extension that they could all settle on, and this was long after DX9 was released.
