OpenGL 1.5 vs 2.0?

[Actuary]

Hi all, in searching for the particular 6600GT I will get, I noticed that all but one of the cards has opengl 1.5 while this one has 2.0. Any major differences between the two?Should I aim for the 2.0 or is it not important?

 

[Dudeyourlame]

hmm im almost sure 6600 Gt's are only Open GL 1.5

 

[foreignkid]

GL support is in the driver. You're probably looking at newegg. Their GL support thing is often wrong.

 

[Hvatum]

Anything recent will support OpenGL 2.0. If it supports all the features depends on the card but for all intensive purposes OpenGL 2.0 is equivalent to DirectX 9.0.

I think a Geforce 5900 will support all the meaningful features of OpenGL 2.0. Just think: If it supports DX 9.0 it will support OpenGL 2.0.

 

[Scali]

OpenGL 2.0 didn't quite turn out to be OpenGL 2.0 anyway.
Basically it's just OpenGL 1.5 with some extensions now standard in the API.
OpenGL is dead.

 

[tornadotsunamilife]

OpenGL 2.0 didn't quite turn out to be OpenGL 2.0 anyway.
Basically it's just OpenGL 1.5 with some extensions now standard in the API.
OpenGL is dead.

Tell that to Quake 4, Prey etc.

 

[Scali]

The API development is pretty much dead, doesn't mean that developers get clued in and stop using it though. Some developers are about as hard-headed as the !!!!!!s on forums like these.
I wonder how OpenGL will react to WGF. The reaction to DX9 turned out to be... very little.

 

[Hvatum]

OpenGL 2.0 didn't quite turn out to be OpenGL 2.0 anyway.
Basically it's just OpenGL 1.5 with some extensions now standard in the API.
OpenGL is dead.

Direct3D API development is driven by Microsoft itself. Every once in a while, they bump up the version number, change the old API, and add some new stuff. Then the graphics cards vendors scramble to support the newest D3D API in their graphics cards. The benefit is that if you write for D3D version X, then the graphics cards your game will run on will support all features, or not work at all. This could be a good thing if you want to throw out a game with a shelf life until the next version of D3D comes out.

OpenGL development, on the other hand, is driven by the graphics card vendors. They come up with a nice feature to distance themselves from the competition (not that there are many competitors these days), and roll it into an OpenGL extension. If the extension is good, others will adopt it, and at some point the extension becomes blessed by the ARB, and will finally end up in the next version of core OpenGL. Take the vertex buffer extension, for example. IIRC, it started as Nvidia's private extension using glVertexArrayRange, then they added fences for double buffering, and then the ARB stepped in and put it under a really nice interface, and now VBOs are part of the newest OpenGL. (But the old extensions are still there, if your program wants to use them!)

The problem with this approach is that a conforming OpenGL implementation does not necessarily support the extensions you want to use in your programs. So you have to add extra logic to query for the extension you want, then enable them (which is a pain), and fall back to alternative rendering methods if it isn't there. I heard rumors that the Doom3 rendering engine is actually several different rendering engines, with the main program figuring out at load time which one is most suited for the implementation it's running on. This adds to the development time, but makes your program scale well (well, maybe Doom3 was a bad example), and it ensures the program will still run years down the road.

I personally much prefer OpenGL's development model to Direct3D's. And there are wrapper libraries to ease the pain of enabling extensions.

And to answer your original question, features of modern graphics cards are exposed under OpenGL and Direct3D, but OpenGL allows card vendors to come up with their own cool stuff without having to wait for Microsoft to deem a feature necessary. So I would think that OpenGL does a better job exposing all functionality than Direct3D - after all, new graphics card generations appear faster than new Direct3D versions.

Features of modern graphics cards are exposed under OpenGL and Direct3D, but OpenGL allows card vendors to come up with their own cool stuff without having to wait for Microsoft to deem a feature necessary. So I would think that OpenGL does a better
job exposing all functionality than Direct3D - after all, new graphics card generations appear faster than new Direct3D versions.

Finally you must remember that non-microsoft platforms need OpenGL so it's here to stay. If you want a fast 3D cross platform game then you must use OpenGL.

 

[Lord of Shadows]

OpenGL is dead.

Cause opengl is just for making games you know...

 

[Scali]

Direct3D API development is driven by Microsoft itself. Every once in a while, they bump up the version number, change the old API, and add some new stuff. Then the graphics cards vendors scramble to support the newest D3D API in their graphics cards. The benefit is that if you write for D3D version X, then the graphics cards your game will run on will support all features, or not work at all. This could be a good thing if you want to throw out a game with a shelf life until the next version of D3D comes out.

I don't see the logic there. Since DirectX is backward-compatible by definition, newer versions of D3D will not have any effect on any code written for previous versions.
So I don't understand the 'shelf life' comment. The games won't suddenly stop working or anything.

OpenGL development, on the other hand, is driven by the graphics card vendors. They come up with a nice feature to distance themselves from the competition (not that there are many competitors these days), and roll it into an OpenGL extension. If the extension is good, others will adopt it, and at some point the extension becomes blessed by the ARB, and will finally end up in the next version of core OpenGL. Take the vertex buffer extension, for example. IIRC, it started as Nvidia's private extension using glVertexArrayRange, then they added fences for double buffering, and then the ARB stepped in and put it under a really nice interface, and now VBOs are part of the newest OpenGL. (But the old extensions are still there, if your program wants to use them!)

That's nice and all, but Direct3D has had hardware vertexbuffer support since DX7, and in a vendor-independent way. So it's not like OpenGL's extensions were a practical advantage over D3D. In fact, they were a disadvantage. You had to write vendor-specific code, and fallbacks when the extensions weren't available. In D3D, it works transparently.

The problem with this approach is that a conforming OpenGL implementation does not necessarily support the extensions you want to use in your programs. So you have to add extra logic to query for the extension you want, then enable them (which is a pain), and fall back to alternative rendering methods if it isn't there. I heard rumors that the Doom3 rendering engine is actually several different rendering engines, with the main program figuring out at load time which one is most suited for the implementation it's running on. This adds to the development time, but makes your program scale well (well, maybe Doom3 was a bad example), and it ensures the program will still run years down the road.

Multiple renderpaths will always be required, if you want to support a range of hardware. But since D3D doesn't have any extensions to worry about, you can reduce the renderpaths required to a minimum, whereas OpenGL will require vendor-specific support for older vertexbuffers, shaders, render-to-texture etc.
Also, as I said before, DirectX is completely backward-compatible, so it ensures that things will still run years down the road aswell.
In fact, DirectX is MORE backward-compatible, because (again) there are no extensions. In OpenGL it has happened more than once that vendors decided to remove older extensions from their drivers, in favour of newer ones (usually ARB).
This means that old code depending on those extensions will either break, or fall back to a less efficient path. This cannot happen with D3D.

And to answer your original question, features of modern graphics cards are exposed under OpenGL and Direct3D, but OpenGL allows card vendors to come up with their own cool stuff without having to wait for Microsoft to deem a feature necessary. So I would think that OpenGL does a better job exposing all functionality than Direct3D - after all, new graphics card generations appear faster than new Direct3D versions.

Again, this is nice in theory, but it doesn't work like that in practice. Things like render-to-texture were only solved properly a few months ago, in some new extensions.
With D3D they got it right the first time, making it far easier to use and more efficient. It's become basic functionality in D3D years ago, and many effects rely on it. Effects that are missing from most OpenGL games.
If a feature is important enough (like SM3.0), MS will release an update immediately. You can pretty much assume that if a feature is not in D3D, it's not worth the trouble (either the feature has very little use or gain, or there is not enough hardware supporting it).

Finally you must remember that non-microsoft platforms need OpenGL so it's here to stay. If you want a fast 3D cross platform game then you must use OpenGL.

That's not entirely true. Not all other platforms have an (efficient) OpenGL implementation. With the PS2 for example, you're tied to custom stuff for good performance. The hardware is far too different from a PC to ever get OpenGL efficient on it.
And the XBox doesn't support OpenGL either. It does support DirectX however.
And for the Mac, there are several implementations of DirectX available, like www.macdx.com, which have been successfully employed in ports of hundreds of PC games.
So it's not like OpenGL is the answer to cross-platform... or that DirectX is limited to Windows only. DirectX's main problem is that it is not ported (yet?) to a lot of platforms.
Besides, if you design your engine properly, then it should not be such a big deal to have an optimized backend for any platform you want to port to, regardless of API.
Even if you use OpenGL, you can't assume that you can run the exact same code on a PC and a cellphone. You'll have to cut down on features that are not supported on other platforms, which may be about as much work as rewriting for a different API... it will just give less-than-perfect results.

 

[Scali]

Cause opengl is just for making games you know...

No, but I did mean it's dead for making games.
For other stuff, it's not such an issue if the API is not entirely up-to-date. Then other advantages of OpenGL may be interesting.
Although, on Windows there are more and more 'professional' applications that are moving to D3D support, like 3dsmax and Autocad for example.

 

[Hvatum]

I don't see the logic there. Since DirectX is backward-compatible by definition, newer versions of D3D will not have any effect on any code written for previous versions.
So I don't understand the 'shelf life' comment. The games won't suddenly stop working or anything.

You might very well be right. I was thinking back to the days of DirectX 5.0 when there were no shortage of version incompatibilities.

That's nice and all, but Direct3D has had hardware vertexbuffer support since DX7, and in a vendor-independent way. So it's not like OpenGL's extensions were a practical advantage over D3D. In fact, they were a disadvantage. You had to write vendor-specific code, and fallbacks when the extensions weren't available. In D3D, it works transparently.

That's nice and all, but things are not so simple. Nvidia's implementation of shaders was tightly tied to a number of uncommon features of their cards, and so in reality the programmer would likely had to write two sets of code anyway. Not until Pixel Shader 2.0 was a similiar enough implimentation standardized that this situation was remedied. By this point OpenGL had introduced its own ARB-approved extensions for both vertex and pixel shader extensions (GL_ARB_vertex_program and GL_ARB_fragment_program) so any DirectX advantage was moot.

Remember also that ultrashadow wasn't supported until DirectX 9.0 but has worked as a vendor extension in OpenGL since day one.

Just because OpenGL has vendor specific extensions before they're ported to DirectX doesn't mean it must lack a standardized specification. Even with a standardized specification different rendering paths must still be implimented as you rightly mentioned. (Half-Life 2 anyone?)

Multiple renderpaths will always be required, if you want to support a range of hardware. But since D3D doesn't have any extensions to worry about, you can reduce the renderpaths required to a minimum, whereas OpenGL will require vendor-specific support for older vertexbuffers, shaders, render-to-texture etc.
Also, as I said before, DirectX is completely backward-compatible, so it ensures that things will still run years down the road aswell.
In fact, DirectX is MORE backward-compatible, because (again) there are no extensions. In OpenGL it has happened more than once that vendors decided to remove older extensions from their drivers, in favour of newer ones (usually ARB).
This means that old code depending on those extensions will either break, or fall back to a less efficient path. This cannot happen with D3D.

Again, this is nice in theory, but it doesn't work like that in practice. Things like render-to-texture were only solved properly a few months ago, in some new extensions.
With D3D they got it right the first time, making it far easier to use and more efficient. It's become basic functionality in D3D years ago, and many effects rely on it. Effects that are missing from most OpenGL games.
If a feature is important enough (like SM3.0), MS will release an update immediately. You can pretty much assume that if a feature is not in D3D, it's not worth the trouble (either the feature has very little use or gain, or there is not enough hardware supporting it).

Read above. That's true to a degree but not true universally.

That's not entirely true. Not all other platforms have an (efficient) OpenGL implementation. With the PS2 for example, you're tied to custom stuff for good performance. The hardware is far too different from a PC to ever get OpenGL efficient on it.
And the XBox doesn't support OpenGL either. It does support DirectX however.
And for the Mac, there are several implementations of DirectX available, like www.macdx.com, which have been successfully employed in ports of hundreds of PC games.

And who made the XBox again?

I also missed the "several" implimentations of DirectX for the Macintosh or the "hundreds" of games ported using these implimentations. MacDX supports only a limited subset of DirectX's API so for anything but simple games it's out of the question.

OpenGL has efficient implimentations in Irix, BeOS, OS2, Solaris, AIX, Linux, OSX (The entire UI IS OpenGL!) and the Playstation 3 which supports a nearly completely standardized OpenGL 2.0.

DirectX supports: Windows, the XBox (though not a standardized version) and Mac (kinda).

So it's not like OpenGL is the answer to cross-platform... or that DirectX is limited to Windows only. DirectX's main problem is that it is not ported (yet?) to a lot of platforms.
Besides, if you design your engine properly, then it should not be such a big deal to have an optimized backend for any platform you want to port to, regardless of API.
Even if you use OpenGL, you can't assume that you can run the exact same code on a PC and a cellphone. You'll have to cut down on features that are not supported on other platforms, which may be about as much work as rewriting for a different API... it will just give less-than-perfect results.

OpenGL is the best answer to cross platform with all competitors left far behind in the dust. Notice first of all that my original point was that no alternative existed for 3D porting besides OpenGL - given that every single game ported to Mac DirectX is 2D this point still stands. You should also realize that any port of DirectX exists only at Microsoft's whim and will be destroyed the nanosecond it is to their advantage to do so. Just look at the legal minefield this type of thing exists in:

http://news.zdnet.co.uk/software/developer/0,39020387,2118968,00.htm

Microsoft has a cold-war sized arsenal of patents on DirectX. if they chose to wield them against DirectX ports then the results would be nothing short of apocalyptic for those foolish enough to depend on those ports. Right now Apple is nothing more than a niche player so the benefit to Microsoft of looking good and moving winning the hearts and minds of developers is greater than any negligable market share loss that Mac DirectX causes Microsoft. Even if the MacDX was in the legal right in such a matter they would be crushed by litigation costs alone.

OpenGL on the other hand exists as an open specification safe from any one vendor's schizophrenic lawsuit bloodlust.

 

[Scali]

You might very well be right. I was thinking back to the days of DirectX 5.0 when there were no shortage of version incompatibilities.

Even back then, DirectX was backward-compatible by nature. The implementations of drivers just weren't all that hot back in those days (but that was an overall problem, generally only Glide worked properly in the old days).

That's nice and all, but things are not so simple. Nvidia's implementation of shaders was tightly tied to a number of uncommon features of their cards, and so in reality the programmer would likely had to write two sets of code anyway.

Why is that? By definition all hardware has to support ps1.1 if they support higher versions (even if those are 'their own', like ps1.4 or ps2.0a/b).
So if you write ps1.1 stuff for an NVIDIA card, it will work on all other cards with shaders, basically.

Not until Pixel Shader 2.0 was a similiar enough implimentation standardized that this situation was remedied. By this point OpenGL had introduced its own ARB-approved extensions for both vertex and pixel shader extensions (GL_ARB_vertex_program and GL_ARB_fragment_program) so any DirectX advantage was moot.

On the contrary. DirectX has the whole SM1.x range support, which OpenGL doesn't offer in a standardized way. So even today, supporting older hardware in OpenGL requires vendor-specific paths.

Remember also that ultrashadow wasn't supported until DirectX 9.0 but has worked as a vendor extension in OpenGL since day one.

Uhhh... That statement is too vague. UltraShadow is a name for a number of features.
Part of it is supported transparently by DirectX, because it is strictly a hardware-feature, and requires no specific API support (when rendering to z/stencil only, fillrate is doubled through some trickery with the pipelines). Another part (depth-range) is not supported by D3D at all.
Sounds like you don't really know what you're saying here.

Just because OpenGL has vendor specific extensions before they're ported to DirectX doesn't mean it must lack a standardized specification.

In practice it does. The ARB works very slowly, and basically they just wait until a vendor-specific extension matures, and then they standardize it.
D3D instead specifies features even before the hardware exists (like SM3.0). Basically the hardware is custom-made to the featureset that is already defined. So it is standardized from day 1.

Even with a standardized specification different rendering paths must still be implimented as you rightly mentioned. (Half-Life 2 anyone?)

Yes, but as I said, D3D reduces that to a minimum, while OpenGL is extension hell (like with the SM1.x shaders, a problem that will never be solved... it will just slowly fade away together with the SM1.x hardware).

And who made the XBox again?

And since when does it matter to developers who builds a certain platform? All they care about is selling games. XBox is just as valid as any other successful gaming platform.

I also missed the "several" implimentations of DirectX for the Macintosh or the "hundreds" of games ported using these implimentations. MacDX supports only a limited subset of DirectX's API so for anything but simple games it's out of the question.

Wow, talk about ignorance.
MacDX is just one example. The only one I know of that is available separately.
The others are used internally by the companies that port the games.
Here's a (non-exhaustive) list of games for Mac: http://www.apple.com/games/features/
As you see, lots of games, and plenty of them are successful DirectX games, such as Halo or Max Payne.

OpenGL has efficient implimentations in Irix, BeOS, OS2, Solaris, AIX, Linux, OSX (The entire UI IS OpenGL!) and the Playstation 3 which supports a nearly completely standardized OpenGL 2.0.

Of those, only OS X and PS3 would be relevant targets for games.
And as you can see, at least on OS X, the amount of ported DirectX games is certainly no smaller than the amount of ported OpenGL games, so apparently it's no issue there.
Which leaves only PS3.
I disagree that linux and BeOS have efficient implementations by the way. BeOS has no official driver support from any popular vendor, making the driver support and performance spotty, to say the least. And linux has support from ATi and NVIDIA, but ATi's support is quite poor, and although NVIDIA's support is considered good, still the Doom3 port appeared to run about 20% slower on a linux system than on the same system running Windows. A 20% difference is not what I call 'efficient'.

DirectX supports: Windows, the XBox (though not a standardized version) and Mac (kinda).

Well, Windows alone has a far larger base than all OpenGL-only platforms combined.
And the XBox version of DirectX is about as standardized as OpenGL on different platforms. Each platform has its own way of handling extensions, and not all extensions may work on all platforms, even when the same hardware is used.

So really, only PS3 would be a proper reason for using OpenGL at this point. But it's not even out yet. And I don't think its impact will be large enough to have people writing more games in OpenGL... I think they'll just stay the way they do now, where the PS will have its own middleware, and ports to different platforms will be done with different APIs.

OpenGL is the best answer to cross platform with all competitors left far behind in the dust. Notice first of all that my original point was that no alternative existed for 3D porting besides OpenGL - given that every single game ported to Mac DirectX is 2D this point still stands. You should also realize that any port of DirectX exists only at Microsoft's whim and will be destroyed the nanosecond it is to their advantage to do so.

There's the Mac-ignorance again, brrrr. Really, you should research before you talk nonsense about things you don't know anything about... Halo is a 2d game? wow!
As for legal trouble... MesaGL can't even be called OpenGL... Did you really think OpenGL was called OpenGL because it's open? No way, SGI has all the rights to it. You have to obtain a license in order to make an OpenGL implementation, and that means SGI calls the shots.

Microsoft has a cold-war sized arsenal of patents on DirectX. if they chose to wield them against DirectX ports then the results would be nothing short of apocalyptic for those foolish enough to depend on those ports. Right now Apple is nothing more than a niche player so the benefit to Microsoft of looking good and moving winning the hearts and minds of developers is greater than any negligable market share loss that Mac DirectX causes Microsoft. Even if the MacDX was in the legal right in such a matter they would be crushed by litigation costs alone.

You're funny, you know that. Microsoft actually is a large game company itself, and has its games ported to the Mac by such a company (www.macsoftgames.com).
Microsoft also is a large shareholder of Apple, so if more games means more Macs sold, that works for them. They have absolutely no reason to go and destroy DirectX on Mac. In fact, there are only advantages. They'd probably even allow a DirectX port on linux, if it means there will be more games made with DirectX, and they can sell their games in a linux version.

OpenGL on the other hand exists as an open specification safe from any one vendor's schizophrenic lawsuit bloodlust.

Guess again.

 

[Hvatum]

Guess again.

Dream on my friend.

Microsoft tried and failed to destroy both OpenGL and Linux wasting tens of millions of Dollars in the attempt. SCO is dead and Microsoft's patents are out of OpenGL so that game is up.

(Just had a minute - I'll respond to the rest later)

 

[Hvatum]

On the contrary. DirectX has the whole SM1.x range support, which OpenGL doesn't offer in a standardized way. So even today, supporting older hardware in OpenGL requires vendor-specific paths.

True perhaps. But then againt that doesn't matter in the slightest since people with such old hardware won't be running the newest games with Vertex shaders activated!

Uhhh... That statement is too vague. UltraShadow is a name for a number of features.
Part of it is supported transparently by DirectX, because it is strictly a hardware-feature, and requires no specific API support (when rendering to z/stencil only, fillrate is doubled through some trickery with the pipelines). Another part (depth-range) is not supported by D3D at all.
Sounds like you don't really know what you're saying here.

How so? It sounds like you knew perfectly well what I meant but chose to misunderstand me. I obviously meant the OpenGL exclusive part. I need not understand the minutia of it's implimentation to understand that it is indeed OpenGL exclusive (Although I thought DirectX 9b/c had gotten it but I could be wrong).

In practice it does. The ARB works very slowly, and basically they just wait until a vendor-specific extension matures, and then they standardize it.
D3D instead specifies features even before the hardware exists (like SM3.0). Basically the hardware is custom-made to the featureset that is already defined. So it is standardized from day 1.

... and available in OpenGL from day -100 and standardized on day 1 also.

Yes, but as I said, D3D reduces that to a minimum, while OpenGL is extension hell (like with the SM1.x shaders, a problem that will never be solved... it will just slowly fade away together with the SM1.x hardware).

True, but I think you're overplaying the difficulty of supporting vendor extensions. It's not the end of the world.

And since when does it matter to developers who builds a certain platform? All they care about is selling games. XBox is just as valid as any other successful gaming platform.

Licensing costs. Online play options.

Wow, talk about ignorance.
MacDX is just one example. The only one I know of that is available separately.
The others are used internally by the companies that port the games.
Here's a (non-exhaustive) list of games for Mac: http://www.apple.com/games/features/
As you see, lots of games, and plenty of them are successful DirectX games, such as Halo or Max Payne.

Read below, neither of these use DirectX for their OSX implimentations.

Of those, only OS X and PS3 would be relevant targets for games.
And as you can see, at least on OS X, the amount of ported DirectX games is certainly no smaller than the amount of ported OpenGL games, so apparently it's no issue there.
Which leaves only PS3.

Really, I count ten games which is much less than half of all OSX games. The list you gave above provided far fewer than twenty games.

I disagree that linux and BeOS have efficient
implementations by the way.

Then you are wrong.

Doom 3 runs on my machine no more than three frames per second slower than or Windows. This owes itself to the lacking optimization of Doom 3 on Linux not slow OpenGL support in my belief. Quake III was afteral optimized by Loki software whereas Doom III was a quick and dirty port.

BeOS has no official driver support from any popular vendor, making the driver support and performance spotty, to say the least.

You're right. I was thinking BSD not BeOS. Chalk it up to writing too quickly again.

And linux has support from ATi and NVIDIA, but ATi's support is quite poor, and although NVIDIA's support is considered good, still the Doom3 port appeared to run about 20% slower on a linux system than on the same system running Windows. A 20% difference is not what I call 'efficient'.

That's the game not the driver. Click the above link for proof of this. I'm also not sure how you managed to make it 20% (!) slower on Linux - are you sure you weren't running it at 1600x1200 accidently?

So really, only PS3 would be a proper reason for using OpenGL at this point. But it's not even out yet. And I don't think its impact will be large enough to have people writing more games in OpenGL... I think they'll just stay the way they do now, where the PS will have its own middleware, and ports to different platforms will be done with different APIs.

I would find that very surprising given that the only intially supported API for the Playstation 3 will be OpenGL. Why should game developers make so much extra work for themselves, are they all masochistic?

There's the Mac-ignorance again, brrrr. Really, you should research before you talk nonsense about things you don't know anything about... Halo is a 2d game? wow!

Wow, you missed again what I said. MacDX has been used to port 2D games exclusively. Here's their official site for more info:

http://www.macdx.com/ (Click on the Games tab)

Anything else is, as you mentioned, is in house and proprietary. Wine has proven to us that reverse engineering an entire API is not easy. Ontop of that unless the implimentation of DirectX was implimented on the driver level the API calls will be translated into OpenGL anyway! That's the height of ineffciency!

I also believe that anything Microsoft ported to the Macintosh is not fair game to be counted as proof of DirectX cross platform worthyness because we don't know what exactly they used and if it was indeed DirectX no other game developer has access. Ontop of that rumor has it that Bungie was planning a Linux OpenGL based version of Halo before they were bought by Microsoft so I'm sure the Macintosh port uses OpenGL. More proof follows,

Imagine the surprise when Bungie decided to unveil the project during Steve Jobs' keynote speech at the Macworld Expo, barely two months after E3. As the highlight of Jobs' discourse on Macintosh game support, designer Jason Jones (who also created Myth) took the stage to present an in-engine demo of the game to the enthusiastic audience. Although there were few changes since we last saw the game at E3, we did manage to corner Jason Jones to discuss the game in greater detail.

Note that this was before Microsofts purchase of Bungie so that wraps up any possibility of Halo being a DirectX based game on Macintosh. Also note the conspicious lack of any forthcoming Macintosh Halo 2 port.

As for legal trouble... MesaGL can't even be called OpenGL... Did you really think OpenGL was called OpenGL because it's open? No way, SGI has all the rights to it. You have to obtain a license in order to make an OpenGL implementation, and that means SGI calls the shots.

I think you've mis-understood how stardards boards work. The OpenGL specification is open to be implimented by all. To use the name "OpenGL" however you must meet a number of qualifications and pass a number of of tests as determined by the architectual review board (ARB) all of which costs money. Programmers working mostly in their free time do not have this money. Read here for more information.

For your information other standards boards also function in the same manner.

You're funny, you know that. Microsoft actually is a large game company itself, and has its games ported to the Mac by such a company (www.macsoftgames.com).

Do we know what API they're using. No - and regardless it's nothing more than a flaky translation layer if it is DirectX based.

Microsoft also is a large shareholder of Apple, so if more games means more Macs sold, that works for them.

This is just inference, but I believe that If anything Micosoft's diverse holdings are in the interest of power not profit. If Apple becomes too threatening and the political environement is amicable Microsoft can more easily buy them out as they did Corel and countless other companies which was intially an "investment."

They have absolutely no reason to go and destroy DirectX on Mac.

Of course, hence they haven't yet. I've already agreed with you on this.

In fact, there are only advantages. They'd probably even allow a DirectX port on linux, if it means there will be more games made with DirectX, and they can sell their games in a linux version..

Really, that explains why Microsoft has repeatedly hampered Wine development efforts. But of course Microsoft has never liked Linux, Opensource or competition.

Sources

Source 1: http://www.gamespot.com/pc/action/halo/news_2460692.html

 

[Scali]

True perhaps. But then againt that doesn't matter in the slightest since people with such old hardware won't be running the newest games with Vertex shaders activated!

What nonsense is that? A game like Half-Life 2 runs fine with shaders on SM1.x hardware, looks great too.

How so? It sounds like you knew perfectly well what I meant but chose to misunderstand me. I obviously meant the OpenGL exclusive part. I need not understand the minutia of it's implimentation to understand that it is indeed OpenGL exclusive (Although I thought DirectX 9b/c had gotten it but I could be wrong).

Your statement was both vague and wrong. Do you even know what advantage the OpenGL-exclusive part will get you? So do you know what you're saying?

... and available in OpenGL from day -100 and standardized on day 1 also.

No, as I repeatedly said. Most standardized ARB-extensions that have been released recently, have been based on the DirectX 9.0 stuff. So standardized WELL after day 1. More like standardized in year 2. And even ripped off from the API you claim it didn't have it available earlier.

True, but I think you're overplaying the difficulty of supporting vendor extensions. It's not the end of the world.

And what makes you the expert? How many game engines have you developed?

Licensing costs. Online play options.

Oh, and Nintendo and Sony don't have those?

Read below, neither of these use DirectX for their OSX implimentations.

Uhhh, yea they do.

Really, I count ten games which is much less than half of all OSX games. The list you gave above provided far fewer than twenty games

Then your counting may be off. MacSoft alone has ported 150 games, most of which are DirectX (if not all, I didn't bother to check every single game).

Then you are wrong.

Doom 3 runs on my machine no more than three frames per second slower than or Windows. This owes itself to the lacking optimization of Doom 3 on Linux not slow OpenGL support in my belief. Quake III was afteral optimized by Loki software whereas Doom III was a quick and dirty port.

I think you are wrong there. The way I see it, Quake 3 was optimized on linux, and was compared to a Windows-version that lacked these optimizations. Doom3 was a straight port (hey, the argument was that OpenGL was portable, right?), so it's an apples-to-apples comparison, and then the linux drivers, kernel and compiler leave something to be desired.

That's the game not the driver. Click the above link for proof of this. I'm also not sure how you managed to make it 20% (!) slower on Linux - are you sure you weren't running it at 1600x1200 accidently?

It's not me, it's some well-known published benchmarks at the time. They even tried it on a 64-bit linux, vs a 32-bit Windows. It didn't help.
The Mac version is also considerably slower btw. Another good example of OpenGL portability?

I would find that very surprising given that the only intially supported API for the Playstation 3 will be OpenGL. Why should game developers make so much extra work for themselves, are they all masochistic?

Developing for a console is far different than developing for PC. On a console, everything is fixed, so you just need one rendering path. So developing with OpenGL on a PS3 is far different from developing on a PC. They may well choose to develop with Direct3D on PC anyway, because it gives them more options and lower development times. They've always done this with PS1 and PS2, so why not now?

Anything else is, as you mentioned, is in house and proprietary. Wine has proven to us that reverse engineering an entire API is not easy. Ontop of that unless the implimentation of DirectX was implimented on the driver level the API calls will be translated into OpenGL anyway! That's the height of ineffciency!

They port at source-level, so they can translate the calls at source-level. It's not comparable to Wine at all. And there is no reverse-engineering involved, since the DirectX docs are freely available. There's even someone who made his own software-emulator for Direct3D, without any reverse-engineering, or any help from MS: http://sw-shader.sf.net
Looks like you have absolutely no idea what you're talking about here.

I also believe that anything Microsoft ported to the Macintosh is not fair game to be counted as proof of DirectX cross platform worthyness because we don't know what exactly they used and if it was indeed DirectX no other game developer has access. Ontop of that rumor has it that Bungie was planning a Linux OpenGL based version of Halo before they were bought by Microsoft so I'm sure the Macintosh port uses OpenGL. More proof follows,

So, even if that's true (which it isn't, by the way), what about all those other DirectX games, like Max Payne, Age of Empires etc... They were all originally linux OpenGL games aswell? I think you're missing the point, you try hard to disprove one game, but there's no way you can disprove all of them.

Note that this was before Microsofts purchase of Bungie so that wraps up any possibility of Halo being a DirectX based game on Macintosh. Also note the conspicious lack of any forthcoming Macintosh Halo 2 port.

How do you know? Halo 2 isn't even on PC yet. I wouldn't be surprised if Halo 2 would eventually come to Mac, but ofcourse the PC version will be first. Then they'll port that one to Mac.

I think you've mis-understood how stardards boards work. The OpenGL specification is open to be implimented by all. To use the name "OpenGL" however you must meet a number of qualifications and pass a number of of tests as determined by the architectual review board (ARB) all of which costs money. Programmers working mostly in their free time do not have this money. Read here for more information.

How exactly does this say anything different than what I said... So how does this explain how I misunderstood it? It looks like I understood it just fine.

Do we know what API they're using. No - and regardless it's nothing more than a flaky translation layer if it is DirectX based.

You might not, but I have spoken to some of these developers who had their DirectX games ported to Mac.

Of course, hence they haven't yet. I've already agreed with you on this.

Yes, and note that this is no different from OpenGL. Both are controlled by 'evil' companies. And if you don't have some weird anti-MS slant, you wouldn't pick on MS specifically.

Really, that explains why Microsoft has repeatedly hampered Wine development efforts. But of course Microsoft has never liked Linux, Opensource or competition.

I don't know of any commercial company that likes competition.Most commercial companies don't seem to like linux or opensource either, seeing as they don't develop for linux or opensource their products. What's your point?
Also, all these links are from slashdot, which is hardly an objective source. It's probably the most pro-linux/oss and anti-ms website on the planet. Heck, if you even read that, you're pretty sick. Let alone if you believe everything they say.

Also, Wine cannot be compared to game ports. Wine verges on illegal activity, with its reverse-engineering of copyrighted and patented code. There's no reverse-engineering involved in porting a game, and you have the sourcecode and all the rights required.

 

[Sly]

OpenGL 2.0 didn't quite turn out to be OpenGL 2.0 anyway.
Basically it's just OpenGL 1.5 with some extensions now standard in the API.
OpenGL is dead.

9 different versions of DirectX vs 1 version of OpenGL. Wow! OpenGL is so dead!

 

[pxc]

9 different versions of DirectX vs 1 version of OpenGL. Wow! OpenGL is so dead!

Naw, OpenGL ARB moves at a snail's pace, but even OpenGL.org claims 2.0 "is the sixth revision since the original version 1.0": http://www.opengl.org/documentation/opengl_current_version.html

The 7 major OpenGL releases (not including x.y.z point releases) since the 1992 public release of OpenGL 1.0:
OpenGL 1.0 initial release
OpenGL 1.1
OpenGL 1.2
OpenGL 1.3
OpenGL 1.4
OpenGL 1.5 (OGL SL introduced as a standard part of the language, more of an interim release)
OpenGL 2.0

 

[Sly]

Naw, OpenGL ARB moves at a snail's pace, but even OpenGL.org claims 2.0 "is the sixth revision since the original version 1.0": http://www.opengl.org/documentation/opengl_current_version.html

The 7 major OpenGL releases (not including x.y.z point releases) since the 1992 public release of OpenGL 1.0:
OpenGL 1.0 initial release
OpenGL 1.1
OpenGL 1.2
OpenGL 1.3
OpenGL 1.4
OpenGL 1.5 (OGL SL introduced as a standard part of the language, more of an interim release)
OpenGL 2.0

(shrugs) As far as i'm concerned, it's still counted as 1 (well, maybe two but i haven't heard of 2.0 being used much), there isn't enough of a difference apparently to call 1.5 as 2.0 so it's still considered as just an update. If we're including revisions, how many versions of DirectX have there been in total? DirectX 9 is already up to 9c.

 

[Scali]

Thing is that they had these huge plans for OpenGL 2.0... New API, new interface, new paradigm etc (just like Direct3D changed a few times to adapt to the new technology, and will change again soon, into WGF).
But none of that came into effect in the end. It's just the same old API, just with some more extensions moved to the core. That's not going to cut it in the long run.
We pretty much have 1 OpenGL engine currently (Doom3), and everything else is Direct3D. I wouldn't be surprised if even Carmack dropped OpenGL for his next game. He did talk about it a few times.

 

[BigDaddy85]

Open GL 2.0 looks dead to me lol

 

[pxc]

(shrugs) As far as i'm concerned, it's still counted as 1 (well, maybe two but i haven't heard of 2.0 being used much),

OpenGL ARB considers it 7 major releases, but you don't. LOL.

You should read the manuals for each revision. A lot of stuff was changed from 1.0 -> 1.1 -> 1.2 -> 1.3 -> 1.4 ->1.5 -> 2.0, sometimes more than what changes in DX whole number revisions.

Since you asked: between 1995 and 2004, MS released 12 major versions of DX, and 4 minor revisions. In 2 years longer than that, OpenGL ARB has released about 1/2 as many major and minor revisions total. So do you consider DX to only have 2 releases?

 

[Hvatum]

What nonsense is that? A game like Half-Life 2 runs fine with shaders on SM1.x hardware, looks great too.

What nonesense is that? The shaders need to be active for them to matter. Have fun playing Half-Life 2 on your Ti 4200 at any decent resolution and quality settings while AA is enabled.

Your statement was both vague and wrong. Do you even know what advantage the OpenGL-exclusive part will get you? So do you know what you're saying?

Not down to the last line of assembler code, but I trust the countless experts who agree with me when one types in "Ultrashadow OpenGL" into google have a very good idea. Here, I'll even do it for you. I do however understand that this feature was first available as an extension in OpenGL which I'm surprised you're still trying to deny.

No, as I repeatedly said. Most standardized ARB-extensions that have been released recently, have been based on the DirectX 9.0 stuff. So standardized WELL after day 1. More like standardized in year 2. And even ripped off from the API you claim it didn't have it available earlier.

You again missed my point which I strenuously I thought I already made clear twice already. Extensions, such as shader model 1.0, are available first (Dictionary.com: The one coming, occurring, or ranking before or above all others) through OpenGL as vendor specific extensions. I therefore fail to understand your fallacious claims that they were "ripped off" from DirectX - how after all can something be "ripped off" if the person accused of the "ripping off" was the first person to integrate the extension?

Furthermore your claim that OpenGL is "ripping (anyone) off" makes absolutely no sense. Neither Microsoft nor the ARB invents these extensions or develops the hardware for them! That work is done by the video card vendors such as ATI, NVIDIA, SGI and 3Dfx. OpenGL and DirectX serve only to integrate these extensions and hardware abilities in an easy use software API after others have invented them. Developers may then chose which of these extensions is the better one. I personally think this ability to chose is a good thing, you I'm guessing do not for some reason.

I completely agree though that DirectX and Microsoft have done more to push ATI and NVIDIA towards standardization than the ARB has. I think though that this has more to do with DirectX's popularity for ATI's and NVIDIA’s target audience than either Microsoft's "innovation" or the ARB's lack of effectiveness.

And what makes you the expert? How many game engines have you developed?

And what makes you the expert? How many game engines have you developed?

I have personally developed nothing more than an extremely buggy basic 3D (Think Wolfenstein 3D Level) game and that was back in 1995. But John Karmack, Atari, the intern at Bioware, Bungi and Microsoft all had no problem using OpenGL and supporting your supposed "extension hell" well crafting awesome games. Maybe the rest of the developers out there just aren't as sharp as they are.

Oh, and Nintendo and Sony don't have those?

Do I need to explain the basics of economics to you? Ok, I'll go ahead and do it.

If licensing costs are higher when producing a game for the X-Box (Licensing Costs=X) than the Gamecube (Licensing Costs=G) and the total profit (Z) is determined using the equation Units Sold-C=Z and Units Sold-G=Z than the game publisher will produce for whichever consol system has the largest Z. Got it?

Uhhh, yea they do.

Proof?

Then your counting may be off. MacSoft alone has ported 150 games, most of which are DirectX (if not all, I didn't bother to check every single game).

Proof?

I think you are wrong there. The way I see it, Quake 3 was optimized on linux, and was compared to a Windows-version that lacked these optimizations. Doom3 was a straight port (hey, the argument was that OpenGL was portable, right?), so it's an apples-to-apples comparison, and then the linux drivers, kernel and compiler leave something to be desired.

Yes, OpenGL is portable. First understand that "able" means nothing more than being :"Especially capable or talented" at something, which OpenGL is. It does not mean "insta-port" with no speed hit whatsoever. The sound system and kernel interactions must still be optimized along with filesystem interactions and other system specific things.

I'm also anticipating your proof that the Linux kernel "leaves something to be desired." The last time I checked it offered true pre-emptibility, hot module loading and better server performance than Windows. That's for another argument though. And the compilier Linux uses is not a "Linux compilier," it's GCC which FYI is used by IBM, Sun and Apple. If you were right though that the Linux kernel and GCC both suck then one would wonder why Quake 3 runs faster in Linux - I guess Windows must really suck!

Oh yeah, Quake 3 was optimized for Linux, haha! Thanks for the laugh.

It's not me, it's some well-known published benchmarks at the time. They even tried it on a 64-bit linux, vs a 32-bit Windows. It didn't help.
The Mac version is also considerably slower btw. Another good example of OpenGL portability?

Fair enough. The first version was not the best, I thought you were talking about the most recent patch. Read above about OpenGL portability and please understand that portability does not equal Java/.Net sandbox.

Developing for a console is far different than developing for PC. On a console, everything is fixed, so you just need one rendering path. So developing with OpenGL on a PS3 is far different from developing on a PC. They may well choose to develop with Direct3D on PC anyway, because it gives them more options and lower development times. They've always done this with PS1 and PS2, so why not now?

Of course, but the OpenGL path has still been developed which would at the least make a drastic cut to the time requried for further OpenGL ports. Again, portability does not mean you can just plop in a CD from one platform to the other and get the same performance or even have it work at all. I think you're getting OpenGL and Java confused.

They port at source-level

Really! I never knew this!!
*drops sarcasm*
What other level would they be porting at? (Sorry I couldn't resist )

They port at source-level so they can translate the calls at source-level. It's not comparable to Wine at all. And there is no reverse-engineering involved, since the DirectX docs are freely available. There's even someone who made his own software-emulator for Direct3D, without any reverse-engineering, or any help from MS: http://sw-shader.sf.net
Looks like you have absolutely no idea what you're talking about here.

Yes they will give them to you if you sign and NDA. Once you've signed this NDA you've gained access to Microsoft trade secrets and cannot go about reproducing them and adding them to your own software as you see fit.

I also think you missed the fact that the Software Shader was implimented in software. The problem as I mentioned earlier is the lack of driver support for Direct3D calls in OSX and Linux. This is something that ATI or Nvidia would need to change. Until they do all Direct3D API calls must be translated to OpenGL. Until hardware support is there any third party Direct3D emulation will be pretty innefficient.

Finally, if making a 3d party D3D emulation layer is so easy why haven't the smart programers working on Wine accomplished it yet?

As a side note drop the Ad-Hoc attacks, they make you look desperate.

So, even if that's true (which it isn't, by the way), what about all those other DirectX games, like Max Payne, Age of Empires etc... They were all originally linux OpenGL games aswell? I think you're missing the point, you try hard to disprove one game, but there's no way you can disprove all of them.

I think this is where the burden of proof comes into play. I've proven something beyond all doubt. Now you either disprove it or the point stands.

You can't just going around saying whatever you like and expect everyone else to spend their time disproving it. If the burden of proof lay always on the same side then someone could just say "There are green trolls who come and night and don't touch anything I know they exist." Someone might then ask for proof and the original person could just say "I don't have any, but you need to disprove it or else I'm right." I think you can see the logical problem with that.

How do you know? Halo 2 isn't even on PC yet. I wouldn't be surprised if Halo 2 would eventually come to Mac, but ofcourse the PC version will be first. Then they'll port that one to Mac.

Halo 2 has been announced for PC. It has not been announced for Mac.

How exactly does this say anything different than what I said... So how does this explain how I misunderstood it? It looks like I understood it just fine.

Meh, you spun it pretty hard to make it look like SGI was some Evil organization pushing down the little man just for the fun of it. I don't love SGI or anything but whatever...

You might not, but I have spoken to some of these developers who had their DirectX games ported to Mac.

The Direct3D game Soldier of Fortune was ported to Linux. Guess what Loki used for their Linux port (Hint: It starts with an "O" and ends with an "L"). Just because a game was ported does not mean it used the original API.

Yes, and note that this is no different from OpenGL. Both are controlled by 'evil' companies. And if you don't have some weird anti-MS slant, you wouldn't pick on MS specifically.

Wow, I guess you missed the fact that we were arguing about DirectX which is owned by Microsoft (that's why I mentioned Microsoft if you still don't understand). The gigantic difference you fail to understand is that anything accepted into the OpenGL by a company cannot be suddenly taken out as the ARB screens for such potentional legal pitfalls. Microsoft tried to do such an "IP Pullout" and failed miseralby as I stated above.

I don't know of any commercial company that likes competition.Most commercial companies don't seem to like linux or opensource either, seeing as they don't develop for linux or opensource their products.

Except for of course SGI, HP, Sun, IBM, Apple, Correl, Redhat, Suse, Dec, ID Software and countless other companies which don't want to re-invent the wheel every time the program something.

Also, all these links are from slashdot which is hardly an objective source. It's probably the most pro-linux/oss and anti-ms website on the planet. Heck, if you even read that, you're pretty sick. Let alone if you believe everything they say.

Did you click on them? All of them lead to objective sites such as ZDnet, Microsoft.com, the New York Times and other well respected news outlets.

Again, stop with the Ad-Hoc attacks, it makes you look very desperate.

Also, Wine cannot be compared to game ports. Wine verges on illegal activity, with its reverse-engineering of copyrighted and patented code. There's no reverse-engineering involved in porting a game, and you have the sourcecode and all the rights required.

Yes, hence all and ports of 3D Macintosh games have used OpenGL.

 

[DizzySHK]

reading this thread gave me a headache...

are you guys programmers?

 

[ludachaz]

now im no expert but i remmember reading an article about the apple switch to x86 and the company that ported halo to the mac said that it would only remove 30% of the time it takes to port something from PC to PowerPC because you dont have to port the proccesor but you still have to port ALL the DX to OpenGL, which is what they did with halo and EVERY other game they ported. So that shows that there is no DX on mac. Then again I could be wrong and by the look of things u get into pissy fits quiete easily so I'll pull out now.

 

[Scali]

What nonesense is that? The shaders need to be active for them to matter. Have fun playing Half-Life 2 on your Ti 4200 at any decent resolution and quality settings while AA is enabled.

No, THAT is nonsense. Shaders don't require high resolutions or AA. Obviously old videocards can't run anything quickly in high resolutions or AA. That doesn't mean that you can't use shaders. In fact, on cards like the Ti4200, shaders are about as fast as fixedfunction. And yes, I played HL2 on my R8500, and it worked fine, and looked good, in DX8.1 mode. It was even playable in 1024x768. In fact, shaders are often faster, because they relieve the CPU of geometry processing, and can reduce the number of renderpasses required. Guess you didn't know that either. But developers do.

Not down to the last line of assembler code, but I trust the countless experts who agree with me when one types in "Ultrashadow OpenGL" into google have a very good idea. Here, I'll even do it for you. I do however understand that this feature was first available as an extension in OpenGL which I'm surprised you're still trying to deny.

I haven't denied that. I denied that it was available in Direct3D. But well, since you don't know what it is, or how to use it, it's useless to discuss it anyway.

You again missed my point which I strenuously I thought I already made clear twice already. Extensions, such as shader model 1.0, are available first (Dictionary.com: The one coming, occurring, or ranking before or above all others) through OpenGL as vendor specific extensions. I therefore fail to understand your fallacious claims that they were "ripped off" from DirectX - how after all can something be "ripped off" if the person accused of the "ripping off" was the first person to integrate the extension?

SM2.0 and higher was what I'm talking about, obviously. SM1.x is still not available in OpenGL through an ARB extension, and never will be.

Furthermore your claim that OpenGL is "ripping (anyone) off" makes absolutely no sense. Neither Microsoft nor the ARB invents these extensions or develops the hardware for them! That work is done by the video card vendors such as ATI, NVIDIA, SGI and 3Dfx. OpenGL and DirectX serve only to integrate these extensions and hardware abilities in an easy use software API after others have invented them. Developers may then chose which of these extensions is the better one. I personally think this ability to chose is a good thing, you I'm guessing do not for some reason.

Well in the case of shaders, yes... NVIDIA first ripped off HLSL with its Cg. Then that morphed into GLSL.
Still it's nearly identical to HLSL.
And if you were a developer, you'd understand what hell the vendor-specific extensions are, and why there are so little OpenGL games. And why all OpenGL games are technically inferior to Direct3D games.

I completely agree though that DirectX and Microsoft have done more to push ATI and NVIDIA towards standardization than the ARB has. I think though that this has more to do with DirectX's popularity for ATI's and NVIDIA’s target audience than either Microsoft's "innovation" or the ARB's lack of effectiveness.

It has to do with Microsoft and the way they're able to organize things and steer a market. The ARB is obviously incapable of any of those things. All they do is standardize extensions after-the-fact. Generally years after they were first introduced. That's lack of effectiveness if you ask me. Taking years to develop a proper render-to-texture interface, that's just pathetic really.

And what makes you the expert? How many game engines have you developed?

I've developed several, both software (various platforms), Direct3D and OpenGL. Well not game engines, but realtime 3d rendering engines nonetheless. So it's the same thing, for the sake of this argument.
But the question was not about me, it was about you. What do you have to back up your claim?

I have personally developed nothing more than an extremely buggy basic 3D (Think Wolfenstein 3D Level) game and that was back in 1995. But John Karmack, Atari, the intern at Bioware, Bungi and Microsoft all had no problem using OpenGL and supporting your supposed "extension hell" well crafting awesome games. Maybe the rest of the developers out there just aren't as sharp as they are.

You'd be pretty blind to ignore the fact that Half-Life 2 and Unreal Engine 3 are the engines where it's happening at the moment, and both just happen to be Direct3D.
And just as I suspected, you have absolutely no experience with actually developing either Direct3D or OpenGL, which makes your opinion on the entire matter uninformed, to say the least.

Do I need to explain the basics of economics to you? Ok, I'll go ahead and do it.

If licensing costs are higher when producing a game for the X-Box (Licensing Costs=X) than the Gamecube (Licensing Costs=G) and the total profit (Z) is determined using the equation Units Sold-C=Z and Units Sold-G=Z than the game publisher will produce for whichever consol system has the largest Z. Got it?

You're arguing the wrong point. You assume that XBox licensing costs are higher to begin with, which is not true.
You also assume that publishers will only produce for the console with the highest potential profit, which again is not true. In fact, it goes against your whole point of games having to use OpenGL to be portable in the first place. After all, if you only develop for one platform, portability is a non-issue.

Proof?
Proof?

Just check the MacSoft site, and mail them to ask how they port their Direct3D games, since you apparently don't take my word for it.

I'm also anticipating your proof that the Linux kernel "leaves something to be desired." The last time I checked it offered true pre-emptibility, hot module loading and better server performance than Windows. That's for another argument though. And the compilier Linux uses is not a "Linux compilier," it's GCC which FYI is used by IBM, Sun and Apple. If you were right though that the Linux kernel and GCC both suck then one would wonder why Quake 3 runs faster in Linux - I guess Windows must really suck!

Well, just benchmark GCC against VS.NET or ICC, and you'll see that indeed GCC is the slowest one in most cases, despite IBM, Sun and Apple using it (realize that they are using it because they use non-x86 processors. x86 has the advantage of having several huge companies developing commercial compilers for it, and it shows).
Why Quake3 is still faster, is because it's not identical to the Windows version. It includes asm-optimizations for SSE/3DNow! that were not available in the original Windows binary (although there is a patched DLL, which I'm quite sure was not used in the benchmarks where linux won). Basically it takes advantage from the fact that it was developed later, and uses more modern technology (probably also in the compiler itself).
If anyone wants to put the effort in, I'm sure if you would optimize and recompile Quake3 for today's systems, on Windows, it'd be faster than linux again.
Which is why the Doom3 port is far more interesting. And your argument of linux needing extra optimizations won't hold, since ID spent a few months working specifically on this linux version after the Windows version was released, and the entire game was designed with Windows, linux and Mac in mind from the start.

Of course, but the OpenGL path has still been developed which would at the least make a drastic cut to the time requried for further OpenGL ports. Again, portability does not mean you can just plop in a CD from one platform to the other and get the same performance or even have it work at all. I think you're getting OpenGL and Java confused.

You might want to drop the condescending attitude. Especially since it seems horribly out of place, given your lack of experience developing with OpenGL. If you did have that experience, you'd know just how much work I'm talking about here.

Really! I never knew this!!
*drops sarcasm*
What other level would they be porting at? (Sorry I couldn't resist )

The point is not whether you know or not. The point is that your argument falls to pieces, because it's based on the wrong assumptions.

Yes they will give them to you if you sign and NDA. Once you've signed this NDA you've gained access to Microsoft trade secrets and cannot go about reproducing them and adding them to your own software as you see fit.

Wrong again. You can download everything you need without signing anything, from http://msdn.microsoft.com

I also think you missed the fact that the Software Shader was implimented in software. The problem as I mentioned earlier is the lack of driver support for Direct3D calls in OSX and Linux. This is something that ATI or Nvidia would need to change. Until they do all Direct3D API calls must be translated to OpenGL. Until hardware support is there any third party Direct3D emulation will be pretty innefficient.

Finally, if making a 3d party D3D emulation layer is so easy why haven't the smart programers working on Wine accomplished it yet?

I think you missed the fact that if you can write a D3D implementation in software, you can also write it in hardware. It doesn't matter where the rendering operations are performed. It matters that they are performed correctly by your software/hardware combination. If it can be done with pure software, it can be done with hardware. Why can't the Wine people do it? Well I have my theories on that too...

As a side note drop the Ad-Hoc attacks, they make you look desperate.

Look who's talking
Problem is that you don't have the experience to back it up.
I'm merely drawing conclusions from the misinformed statements that you utter.

I think this is where the burden of proof comes into play. I've proven something beyond all doubt. Now you either disprove it or the point stands.

Erm, what did you prove? That there are rumours about Halo originally being targeted for linux and OpenGL?
Even if those rumours are true, that doesn't mean that the Mac version is OpenGL. Since the final version for XBox and Windows uses Direct3D, it could just aswell be that they ported that version. You don't know how much of an OpenGL version was actually developed. Perhaps it never got further than an idea, that was dropped before development started. I don't have to prove that Halo for XBox and PC is Direct3D, do I?
You have to prove that the OpenGL version of Halo exists, and is just as mature as the Direct3D version, and was used as the basis for the Mac port, rather than the Direct3D version.

Halo 2 has been announced for PC. It has not been announced for Mac.

It could still be announced later ofcourse. Mac ports are always later than PC or console versions.
So just because it's not announced yet, doesn't prove that it won't ever happen.

Meh, you spun it pretty hard to make it look like SGI was some Evil organization pushing down the little man just for the fun of it. I don't love SGI or anything but whatever...

Apparently you didn't get the point. You were doing the same with MS and Direct3D. I was just pointing out that apart from some anti-MS sympathies, the situation with OpenGL is really no different.

The Direct3D game Soldier of Fortune was ported to Linux. Guess what Loki used for their Linux port (Hint: It starts with an "O" and ends with an "L"). Just because a game was ported does not mean it used the original API.

No, but obviously the volume of games ported to Mac is much higher, and the development times are much shorter. Which is a clear indication that they may use a slightly different way of porting.

Except for of course SGI, HP, Sun, IBM, Apple, Correl, Redhat, Suse, Dec, ID Software and countless other companies which don't want to re-invent the wheel every time the program something.

As I said, *most* companies don't.
These particular companies are interested because they can (ab)use opensource in a way that's a win to them, not a loss. That doesn't go for most companies.

Did you click on them? All of them lead to objective sites such as ZDnet, Microsoft.com, the New York Times and other well respected news outlets.

No I didn't. I'm not interested in anti-MS propaganda. I'm interested in the technical part of the Direct3D vs OpenGL discussion, but apparently you ran out of arguments there.

Yes, hence all and ports of 3D Macintosh games have used OpenGL.

Yes, I never denied that. If you bothered to look into MacDX, you'd see that this was also a wrapper around OpenGL. Obviously all the other similar products work in the same way, because there are no native 3d drivers for MacOS other than the OpenGL ones. So at some point you have to wrap to those drivers.
The point is just that they don't rewrite all DirectX code to OpenGL and other APIs, but rather use these wrappers directly, which makes porting about as easy, if not easier, than porting an OpenGL game (which after all, was the original point in this discussion).
I guess you sidetracked so far that you don't even know what we were talking about in the first place.