Direct3D 10/11 Is Now Natively Implemented On Linux!

[crazycheese]

Also, the fact that D3D isn't open is only important to "Freeness" lunatics. I couldn't care less.

Freeness lunatics? Im very very happy for you, your fingers.dll license has not yet expired and the producer still supports your brain.com with patches, although its gonna be outdated soon.

And how about your heart.exe monthly $1,000,000,000 renewal fee? Sadly only this model is compatible to the rest of yours. In fact it is the only available model because it is a non-replaceable proprietary world standart.

[Svartalf]

(a) You didn't answer my question. Name a single AAA OpenGL game please.

Let's see...

Quake III:Arena
Doom III
Quake IV
World of Warcraft (We tested it at AMD when I was doing work for them...as an OpenGL sustaining engineer...)

Oh, you meant recent stuff...hm...

Chronicles of Riddick: Escape From Butcher Bay (Yes...)
Portal (MacOS version...)
Doom4 (Claimed...)

Heh...name one...just go looking around- there's quite a bit.

(b) Obviously, considering that Direct3D is the better programming API. Long Peaks might have changed that, but Khronos backed off before it was complete.

Nope. It wasn't a "better" one. It just exposed "nifty" stuff that might have "simplified" some of the graphics effects programming.

(c) MS taking de facto ownership of 3D wouldn't be such a bad thing, considering how awful the 3d stacks on Linux/BSD/Mac/Unix are.

They're not awful- they're poorly implemented in the case of some aspects thereof (differing ones for NVidia and AMD...)- and this isn't the fault of the API and more a fault of the vendors not putting quite enough manpower against the issue in question. And, more to the point, this doesn't fix that issue- a D3D state tracker won't magically make it "better", full on drivers with it might, but then they'd also make the 3D stack situation with OpenGL better as well.

[Pickup]

It sounds a bit scary: D3D games will run on Linux, but D3D will become a platform for linux game developers too (which means: M$ will condition part of the linux environment developing) or even worse: no more native games on linux (why bother doing a linux version if the windoze one runs so fine on top of wine?).

But this might turn out to be the beginning of a sane competition: to do what you can to improve the (far more free) OGL stack and raise it to a level higher than D3D!

Why not?

[pingufunkybeat]

I can't comprehend how many people here WISH that Microsoft takes complete control over Linux 3d graphics.

Holy shit.

And then we wonder when so many people wish that the Free drivers die, so WINE would work better....

[Svartalf]

I can't comprehend how many people here WISH that Microsoft takes complete control over Linux 3d graphics.

Holy shit.

And then we wonder when so many people wish that the Free drivers die, so WINE would work better....

Most of them think it's a way to get games easier. In truth, for most cases, the D3D part's a) not insurmountable, b) NOT the bulk of the effort porting a game over, and c) NOT the reason you don't have games on Linux in the first place.

It's not going to magically make WINE do better- they need to make a .so that allows it to use that D3D state tracker.

It's not going to magically make game porting easier unless someone implements D3D's API layer (which is the piece that talks to the state tracker...) on Linux.

It's not going to magically get more games ON Linux- the studios have to see a need for making them available (Having WINE makes this a problem, mind...).



They see what they think is the quick and easy path. They've not watched the whole story pan out over decades of time. I have. I was where they were at one point in time- but then I saw that what I had wanted and they now want is actually counter productive.

[pingufunkybeat]

Games should be developed with whatever the one doing the development feels like using. And if the choice is D3D, then this tracker is useful and needed.

In other words, games should be developed for Windows (since Direct3d is a part of Windows), and it's the responsibility of Linux to make sure it is completely compatible.

Same argument can be made regarding using other Windows technologies, such as MFC, and that WINE should be able to run that.

Terrible, terrible idea.

No, people should develop portable software, using portable solutions. It's not up to Linux to run unportable, monopolistic and poorly designed software which was explicitly created with the goal of NOT running on Linux.

[Craig73]

So implement Open GL 3x/4x cleanly on Gallium3d. Either way, the more API's available to choose from, the more use cases Gallium3D suits. The more used Gallium3D is, the more the various layers and hardware support are polished and bugs removed. I'm less concerned about the API as having a polished driver...

[Craig73]

So implement Open GL 3x/4x cleanly on Gallium3d. Either way, the more API's available to choose from, the more use cases Gallium3D suits. The more used Gallium3D is, the more the various layers and hardware support are polished and bugs removed. I'm less concerned about the API as having a polished driver...

(and FWIW, Gallium3D being used in virtual machines, or on ReactOS (a Free windows implementation), etc., might all be valid use cases for open implementations of MS technologies... )

[mirv]

Oh great, this hyped up story just hit slashdot.

[RealNC]

Uh, it has less to do with "Freeness" and more to do with the fact that D3D isn't available on:

PS3
Wii
MacOS
Linux

You either have OpenGL or OpenGL ES as a target for those systems. As for Linux, this includes:

X86
X86-64
ARM (Heh... Let's see... WebOS, MeeGo, Angstrom (Pandora), Android,...)

In the end, you need to target BOTH API's because your game will sit on everything if you want it to at that point. Why limit yourself to just Microsoft based systems when you're going to leave at least 20-30% of the total market on the floor if you do?

Because D3D is easier to use than OpenGL?