DirectX 10 Coming To Linux and Mac 152
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.'"
Good news for normal Wine too (Score:5, Interesting)
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.
Why not work on another API? (Score:5, Interesting)
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)
Wine or CrossOver? (Score:1, Interesting)
Re:Good news for normal Wine too (Score:5, Interesting)
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 (Score:3, Interesting)
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 [europa.eu]:
"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:Why not work on another API? (Score:5, Interesting)
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?
My kingdom for Rogue Squadron! (Score:3, Interesting)
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:Getting rid of Windows (Score:2, Interesting)
As much as I'd like to see *nix do better I hate openGL with a fiery passion. I'll grant that the generally lower performance and responsiveness is almost guaranteed to be the developers fault rather than opengl... 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.
Re:Getting rid of Windows (Score:3, Interesting)
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:
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 (Score:5, Interesting)
Re:Good news for normal Wine too (Score:4, Interesting)
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.
Re:Getting rid of Windows (Score:3, Interesting)
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;
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 (Score:4, Interesting)
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 (Score:5, Interesting)
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.