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

[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

[telchine]

In the end I bought a console and didn't look back.

Yeah, that's the problem I have with console games too... you can't look back very easily.

With a controller, turning around to look behind you is a slow and cumbersome task. I much prefer a keyboard and mouse because you can spin around in under a second, it makes the game feel a lot faster.

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

[robthebloke]

uhm, when you say third party app, do you mean the graphics card driver? (Since you only need to disable v-sync in the graphics card options and the problem is gone)

Re:Getting rid of Windows

[Novus]

but requiring me to go get a third party application purely to keep my monitor from being forced to 60hz every damn time I boot up the game pisses me off.

There are two possible reasons for this:

• The application explicitly requests a 60 Hz refresh rate; for many applications it makes sense to match the refresh rate to the frame rate, which may be fixed either to have a consistent frame rate over all systems (and 60 Hz is more or less universal for PCs) or because you have content with a specific frame rate (e.g. 60 fields/s M ("NTSC") video).
• The operating system or video driver defaults to 60 Hz or overrides the selected value.

OpenGL does not even support switching screen modes and often relies on OS-specific mechanisms. DirectX often suffers in my experience (and based on some web searches, in many others') from similar problems and the most common X11 implementations provide screen mode switching mechanisms that are clearly independent of OpenGL and easily (in the "just write lots of numbers into a text file" sense) configured for specific monitor timings.

In conclusion, I can probably make some of the resident Linux zealots happy by saying your problems are probably with Windows, not OpenGL.

Re:Getting rid of Windows

[TheRaven64]

One of the interesting, but less-often mentioned, things about WINE is that it works on Windows. If WINE adds support for DirectX 10, then this makes it possible to run DirectX 10 games on Windows XP, which gives home users a reason not to upgrade to Vista / Windows 7.

Re:Getting rid of Windows

[robthebloke]

That's got nothing to do with the graphics hardware at all, it's crap programming. You can enumerate all supported display modes, and you'll generally pick either the highest one, or the current display mode (or offer a choice).

At a guess, I'd say that the game jumping to 60Hz is due to a fixed time step being employed within the update loop of the game (in general this is because physics engines don't work very well with variable time steps). If you do this kind of thing, you have to divorce the rendering from the game update - which some people are pretty bad at doing.

This sounds like it's a case of the game develeoper trying to optimise the code in pretty crap ways such as replacing this:

position += time_delta * 2.0f; // where 2 is speed

with this:

position += 0.03333333333f;

To remove a few mults at runtime. (my opinion is that that stuff just isn't worth doing).

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

[BPPG]

makes you look childish.

Oh anonymous coward, your criticisms see into our very souls.

Re:Getting rid of Windows

[jbarlow]

I honestly haven't seen a 60hz LCD for years. My four-year-old Samsungs are running at 75hz, and current nicer TVs run at 120hz.
 
/takes off pedantic hat

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.

Re:Getting rid of Windows

[Creepy]

The reality is having a refresh greater than 60Hz is pretty pointless with an LCD because there is no phosphor being strobe blasted with scanlines where the eye can detect the flicker and most people can't detect changes faster than 1/30th of a second, much less 1/60th.

    The only use I can think of for 120Hz on a TV is because traditional movies are recorded at 24 frames per second (12 for cartoons, but they double frame) and TV at 30FPS, and since 120/24=5 and 120/30=4 you don't have to double any frame like you would for 60Hz (and 75 is worse...). Still, you are repeating the same frame either 4 or 5 times and since LCDs don't flicker it's overkill (if you slowed refresh for that movie down to 24FPS it'd look just as good). While some professional digital cameras are recording 120FPS or more, it takes a ton of memory to store continuous video at that frequency and I don't foresee that being an issue in the near future (it's certainly more useful from a video editing viewpoint than a TV watching viewpoint).

Re:Getting rid of Windows

[Kazoo the Clown]

The reality is having a refresh greater than 60Hz is pretty pointless with an LCD because there is no phosphor being strobe blasted with scanlines where the eye can detect the flicker and most people can't detect changes faster than 1/30th of a second, much less 1/60th.

This is probably true if they're calculating motion blur, but pumping up the refresh rate is simpler. We're not talking about flicker of static images, but the stepped-motion of moving ones. An object that flies across a 1920 pixel screen in one second, shifts 32 pixels a frame at 60hz, and 16 at 120hz. These are differences you can see.

Re:Getting rid of Windows

[Bert64]

You can use 2003, the 32bit version supports more than 4gb of ram (xp could too, its artificially crippled and aparrently non service packed versions do) and the 64bit version works a lot better than xp64 ever did.

Re:Getting rid of Windows

[malevolentjelly]

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).

It's interesting you say luxury there because it takes a lot less time and resources to develop a game for Windows due to superior API's and vastly superior development and testing tools. It's not like game developers are brainwashed or anything- they're just time and budget constrained. Games are tremendously complex and extremely resource intensive, it takes a very consistent and sane environment to do complex modern games.

You're welcome to mod me down, but this is a huge gap in the linux development ecosystem that someone should take seriously. I recommend doing this through the mono project or java because of their nice development tools and consistent environments.

Until the open source world has something comparable to DirectX or Visual Studio or something (if you mention SDL or gdb, I will laugh at you) it might be in their benefit to keep cultivating the wine project to stay on-board with games. Even Apple is behind in this category, and they have REAL development tools (in fact, many new games are getting ported to mac through the Wine-derivative Transgaming Cider). This is one category where Microsoft is leading in more than just OEM-pressure, unfortunately.

Re:Getting rid of Windows

[default luser]

PAE won't help with this problem, because it splits the memory space into multiple 4GB chunks, and you can only access one chunk at a time. Technically, you could have a game use more than 2GB ram using PAE, but the performance hit switching between memory spaces is astronomical, so you'd have to find a way to streamline it.

A flat 64-bit memory space is so much easier. PAE was really intended for multiple server processes to run at-once, with a small hit for process switching. Nothing real-time was ever intended for PAE.

Good news for normal Wine too

[Novus]

With Wine under the LGPL (making much of CrossOver LGPL) and CodeWeavers supporting Wine development, this will probably result in standard Wine also supporting DirectX 10 soon. I can also see this becoming a DirectX 10 to OpenGL wrapper to provide DirectX 10 features on XP. Both of these would be nice.

Re:Good news for normal Wine too

[IBBoard]

I can also see this becoming a DirectX 10 to OpenGL wrapper to provide DirectX 10 features on XP.

That's the wonderful irony about this - Linux, the non-gaming desktop, is going to get DirectX 10 through open-source while Microsoft just ignore the huge majority of people on Windows XP!

Not that I use any games that are DX10, but this is definitely an interesting development.

Re:Good news for normal Wine too

[Elektroschock]

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. Sure, it is complicated but the contribution process does not look good. The wine project still does not scale properly in its development.

It also could not be too difficult to cut Wine in pieces and e.g. raise funds for the full and complete implementation of a particular API or the full support of a particular program. It does not happen. I cannot fund the whole API but I would be capable to give a bounty for a particular function. The monolithic development process does not permit real progress. No one knows why a patch is accepted or rejected.

Wine has specific coding styles but no automated quality process like the KDE guys did with Krazy/EBN. And the wine tests used for compatibility checks are known to be very buggy. Wine is nothing but a messy implementation of the Win32 mess.

I also don't see Wine on the political advocacy sphere to urge policy makers to apply stick and carrot for Microsoft to disclose API details, this is a quote from a Microsoft memo found in the 2004 EU antitrust case documents:

"The Windows API is so broad, so deep, and so functional that most ISVs would be crazy not to use it. And it is so deeply embedded in the source code of many Windows apps that there is a huge switching cost to using a different operating system instead...

        "It is this switching cost that has given the customers the patience to stick with Windows through all our mistakes, our buggy drivers, our high TCO, our lack of a sexy vision at times, and many other difficulties [...] Customers constantly evaluate other desktop platforms, [but] it would be so much work to move over that they hope we just improve Windows rather than force them to move.

        "In short, without this exclusive franchise called the Windows API, we would have been dead a long time ago."

That is more than a smoking gun, hein? Don't you think it would have been possible to get funds from governments and industry players that are stuck with their strategic dependency on Win32? The wine project, despite its stupid patch rejection policy does meet ordinary quality standards in any part and is incapable in its managements to enable and encourage such contributions.

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:Good news for normal Wine too

[TheRaven64]

That's the wonderful irony about this - Linux, the non-gaming desktop, is going to get DirectX 10 through open-source while Microsoft just ignore the huge majority of people on Windows XP!

You seem to be missing the fact that WINE works quite well on Windows (and Mac), and so if WINE supports DirectX 10 then so does XP. A few desktop VM apps are using WINE code to provide DirectX drivers which talk to the host platform's OpenGL implementation. I wouldn't be surprised to see some game publishers investing a little in WINE development and shipping WINE DLLs along with their app to run on XP. This would also give them Mac (and Linux) ports effectively for free.

Why not work on another API?

[Anonymous Coward]

Surely with the likes of IBM, Apple, EA, Sun (shudder), Valve, ATI, Nvidia, all teaming up, they could create a cross platform API, and all appropriate documentation, programming plugins etc that will make programming for it easier than DirectX?

I mean, it's not the wildest concept ever. Clean up OpenGL, make it simpler if required. Add Open sound, add openinput, and voila!

If it's simple to code for, well documented and supports all of the latest features, and is downloadable as a library for all of the major windows' and *nix's it will make life easier for gamers, developers and other open source advocates.

It could be like java in concept, but more like directx in function. (ie it works)

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.

Re:Why not work on another API?

[kripkenstein]

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.

Is that still true? All the major 3D engines - Gamebryo, CryEngine, id Tech (5), Unity, etc., can output to DirectX, OpenGL and various console graphic systems. And at the low end even open source engines like Ogre and Irrlicht can output to multiple renderers.

Are there still a lot of Windows games that write raw DirectX code?

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.

Good news, bad news.

[Anonymous Coward]

The good news: increased base of support for games.

The bad news: Codeweavers makes much noise about their "supported games". But what they don't make explicitly clear is that these games are, for the most part, games that have been reported to work. Don't take my word for it, go and check. Out of 174 games listed on that page, one is "known not to work", 149 get an "honourable mention" (meaning they've been reported to work, but they are not supported by Codeweavers), two get a bronze, and 22 get a silver. So that's 174 games listed, and just 24 of those are supported if there are issues.

Rather disingenuous, really, to have that information tucked away in a pop-up tooltip that only appears when you hover over the medal. I wish them luck, but I can't help but feel that they need to be a little bit more open with their customers.

It also doesn't help that that list hasn't been updated since July ... eight months. Not exactly confidence inspiring, alas.

Re:Good news, bad news.

[jparshall]

Here's the deal, guys. We're not trying to be disingenuous. But we also have finite resources, which means we have to be very careful about what we bite off in the support department. Here at the ranch, we have this funny belief that officially supporting a game means we *actually* have to care about it. That means that we have to treat our customers' questions about that game with some amount of due diligence, stoke up developers to fix bugs on it, etc. Sadly, there aren't enough support engineers on the planet to answer every 13-year old kid's questions about why this one particular sprite in Foozlewars Xtreme 10 doesn't quite render correctly on alternate Sundays under CrossOver. If we officially supported every game we ran, we'd have to put guns against our temples. And that wouldn't be good for Wine development as a whole, now would it? So, mostly, we only officially support the "big hitters" out there, the hot titles, because let's face it, for every World of Warcraft and Team Fortress 2 there's about a buhzillion other titles that *may* run, but only have about 14 passionate players. This, in turn, means that "officially supporting" Foozlewars Xtreme 10 doesn't drive all that much revenue to my bottom line, whereas supporting WoW and TF2 sure as hell *does*. And the bottom line about the bottom line is that the more ca$h there is *under* the bottom line, the faster Wine gets better. But right now, today, while we'd love to support everything, we simply don't have the resources to do it. We thank our customers profusely for giving us the resources we *do* have--your patronage has directly improved Wine. -jon parshall- COO www.codeweavers.com

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:Misleading title

[wwphx]

Rats, I was hoping for a way to make my MacBook Pro less stable. Rebooting my Axim almost daily just isn't enough for me.

Porting to XP?

[RenHoek]

It would be nice if this were to be ported to Windows XP and take away the only reason why I would ever consider Vista/7

Re:Porting to XP?

[David Gerard]

Working on it!

(Status: doesn't actually, er, compile as yet. And even if it did, the program launcher wouldn't work. But more people to at least solve the inability to compile would be most welcome. Current block: Cygwin's header files are on crack.)

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.

My kingdom for Rogue Squadron!

[Progman3K]

I love the Wine project.
I have seen it mature to where it is amazingly able to reproduce Windows (bugs and all!) which is NO SMALL FEAT.
I've installed Crossover Office for someone and seen it able to run Office perfectly.

I just wish in all of that it was able to run Rogue Squadron, an old Windows 98 game because that is really the only game I miss.

But I suppose Rogue Squadron is too much of an oddball; it's old and probably relies on some undocumented jazz in Windows 98...

Re:oblig, even though it was a funny one

[Chabo]

WHOOOOSH!