DirectX 10 Coming To Linux and Mac

twickline writes "Jeremy White posted the 2009 roadmap for Crossover, and wrote, 'We've just shipped a lot of those "under the hood" improvements for games out in CrossOver Games 7.2. We're really pushing Direct X 9 support pretty far along, and getting ready to move on Direct X 10. ... In addition to our normal work of broadening and deepening our application support in Wine, we're going to try to dramatically improve the CrossOver GUI itself. First, the Linux version will get a fresh new look. But both versions are going to get an interface that we hope will bring the power of the Compatibility Center right into the installation view. The key idea is to make it easier to distill the gathered wisdom on unsupported applications and make it far easier to use.'"

Comments

Getting rid of Windows

[tomalpha]

The only reason I still have a Windows PC at home is for gaming. DirectX 10 support is a step closer to me being able to get rid of it. Can't come soon enough, and I'm happy to pay for it if that's what it takes.

Re:Getting rid of Windows

[Anonymous Coward]

Once you are able to play DirectX games, DirectX 12 will be on its way. Even some old DirectX8 games aren't running still now because support only goes in for very few extremely popular games that pay Crossover's bills and Hentai games.
I just gave up and play nethack.

Re:Getting rid of Windows

[sinthetek]

As long as DirectX is still in use, *nix will always still be a step behind Windows in gaming. Personally I would be pushing for game developers to support OpenGL more than WINE developers to support DirectX

Re:Getting rid of Windows

[MetaPhyzx]

One has to weigh the push M$ has put behind cultivating coders who feel comfortable doing things in DX (with the advantage of support from M$), versus the shops that have the luxury to tool around in GL (id software and a few others).

Being able to pick up a phone and get support is huge to them, with the added bonus of writing for a select set of API's that are supposedly guaranteed to work with the varying M$ operating systems.

Don't get me wrong; I agree with you. But as the old saying goes: Money talks; bullsh!t...

Re:Getting rid of Windows

[BrokenHalo]

Using 'M$' only makes you look childish. Actually it's worse than that, it makes you look like Twitter.

Childish, maybe. Who cares? But people have been calling Microsoft M$ far longer than Twitter has been around on Slashdot.

Re:Getting rid of Windows

[default luser]

This would've been nice two years ago, but we are already at the 4GB barrier. And sadly we are out of options. If available memory cannot increase, the quality of games will not improve. Yeah, you can go XP-64, but from what I've seen, it's not nearly as good as Vista/7 64. And if you're going to upgrade to XP-64, you might as well consider 7 instead.

In addition, the demand just isn't there anymore. There was a huge clamor for DX10 in XP when Vista was released, but now that's died-down. It turns out that a lot of good games don't support DX10, and most of those that do have huge performance hits for small graphical improvements, or small performance gains with no graphical improvements. The slowing sales of Vista are proof-positive that DX10 is not a selling point anymore.

Misleading title

[Totenglocke]

Direct X 10 coming to Linux and Mac falsely implies that MS would be making it possible for Direct X 10 to be run natively on Linux or Mac. A much more accurate title (though one that many would read and say "who cares" without clicking on the link) would be "Crossover Games to support Direct X 10.

Re:Why not work on another API?

[Sneeka2]

Oh, and ponies please while you're at it, m'kay?

Unfortunately, this is much less of a technical issue than a business issue. Developers are entrenched in DX development, and Microsoft will try to keep it that way. That's the real problem that needs to be solved.

It's all lies.

[Computershack]

The last time I played a game using Crossover, it was in DX7, not 9, so I don't know how they can claim that's the case. For those still reading, it was CS:Source and Battlefield 2. Both looked truly horrific compared to playing on Windows and had poor framerates despite being run on a 9600GT.

And then there's Punkbuster support. Until they can get that working 100%, there's no point at all because you end up getting blacklisted so that money you spent buying the game is wasted as your CD Key is unusable on any PB server.

Re:Good news for normal Wine too

[kazade84]

I have the impression that the sponsorship rather contributes to no improvements. Best example is the DIB engine. First implementations were proposed years ago but always rejected. It was said it takes like 3 month. Still there would be the option to introduce a DIB engine in a branch and stablize it. It won't happen. We probably have the fourth DIB engine implementation now. The patch rejection policy of the dictatorial project leader can be explained and rationalised by underlying commercial objectives of the commercial implementations which gain here competitive advantages or utter mismanagement of the development process.

I think that's a little unfair. The DIB engine has been rejected several times because noone has yet managed to implement it in a way which doesn't cause MASSIVE regressions. The DIB engine implementation is huge, Alexandre Julliard (the "dictatorial project leader" as you put it) won't accept code which breaks Wine or is the wrong approach. He also won't accept one massive patch which may cause a tonne of regressions, I don't blame him for that.

I believe the current DIB engine which is being worked on is still going to be rejected because it hasn't solved the fundamental problem with the other approaches - how to implement it in small incremental stages.

I have NEVER seen a patch rejected by AJ for any reason other than it's technically unsound, if your patch is rejected you simply ask in #winehackers and AJ will be happy to tell you what's wrong. His rejections have nothing to do with the commerical applications of CodeWeavers, it's down to code quality.

Re:Why not work on another API?

[robthebloke]

Not really, everything has gone towards shaders, and it's trivial to port a GLSL shader to a HLSL one and vice versa.

The real problem for GL developers is that the API is lagging behind DX, and has been for a number of years. So, new features get added to D3D, and then ATI/NVidia will implement extensions for those into GL. About a year later, those may be unified into a single ext or arb extension. About 3 years later, they may find their way into the core SDK (at which point D3D would have had those in the core SDK for 3 years).

Developers aren't entrenched in D3D, they just find a much nicer API to work with.