Slashdot Mirror
Windows Games On Linux
Warrior-GS writes "Transgaming is working on a process that allows Linux users to play Windows games. According to their CEO, Gavriel State: "Essentially, TransGaming's work allows gamers to take off-the-shelf Windows games and run them directly under Linux. It won't run every game out there at first, but 100% compatibility is our long-term goal. To accomplish this, we have been working on a new Linux implementation of the DirectX multimedia APIs. Our work is closely tied with the Wine project -- an Open Source effort to implement the Microsoft Windows APIs on Linux -- in essence, a Windows compatibility layer. Wine is not an emulator in the traditional sense -- it doesn't emulate a CPU or any other hardware -- it loads and executes Windows programs directly on your Linux hardware without the need for any Microsoft code to be installed at all."
The whole interview can be found at GameSpy."
If you really want a good gaming environment (both for user system choice and programmer enjoyment) support Indrema, and write your games using OpenGL, IP, and as many other open standards and tools as you can. Then, you'll be poised to release on Windows, Linux, MacOS X, QNX, BeOS and whatever other interesting new systems pop up.
Don't get sucked into the Windows food chain - you know who sits at the top! (Plus they can't design system software worth a damn.)
186,282 mi/s...not just a good idea, its the law.
More games is a good thing, but non-native application support for linux is the last thing we want.
Look what happened to IBM's OS/2 platform. The windows emulation was so good that native OS/2 applications were never written. And once Microsoft pulled the rug out from underneath IBM with Win32, OS/2 died.
If Linux is to thrive in the consumer market, then it must do so on its own merits. Settling for weak Microsoft emulation is a step backwards.
Nothing will replace native support. When native applications are written for a platform, others will decide to start porting to this popular platform. If they only see non-native support, then they won't bother.
Why would you put the effort of writing for two code bases if only one would suffice? You wouldn't; that's obvious. So we'll end up with a world of Windows applications and none for Linux.
This would be fine, if we could trust Microsoft not to change the Win32 API, but can we? They're going to have to switch to a Win64 API soon. Will we be able to catch up?
It'd be better not to tie Linux's future to shoddy emulation efforts. Even if it's not true "emulation" in that sense, it still is vulnerable to the sort of problems that regular emulation is: all Microsoft has to do is change a couple libraries and we're back out in the rain again.
Real Linux Support Now. Don't settle for anything less.
True, which is why I'm hoping this won't be Linux-centric--I run a freer OS than "GNU/Linux".
Stating on Slashdot that I like cheese since 1997.
There was a discussion on WINE on kuro5hin this week. For all the number of people posting crap about the supposed superiority of k5 over
The story asked the following question: instead of hounding companies to port, why not help with WINE? The responses were divided between:
1. WINE doesn't work that great right now
2. I think it's bad 'coz there's no incentive then to write native and/or Free apps
Now #2 I can see, but #1? The story was asking why people don't help improve WINE! Duh! One jerk went so far as to say that all WINE was for was to run Windows programs under Linux. Even when the subject of Winelib came up. Um, duh, Winelib is a library to help make porting easy. Heck, Microsoft products usually get ported to other platforms through such software, though usually commercial software...
This sounds like a great solution because Windows doesn't look to be on its deathbed quite yet, and there's this odd backlash against Linux on the desktop. It's starting to look like we'll be stuck with Windows shrinkwrap and Free/Open clones for a while yet...
Stating on Slashdot that I like cheese since 1997.
Forgive me if I fail to share your optimism.
Stating on Slashdot that I like cheese since 1997.
For people who actually do work with their machine, rebooting simply isn't an option -- I have simulations running that can take weeks to complete. Making them run slow for a while is okay -- killing them by rebooting is *not* okay.
Hell, no! If you are going to improve on DirectX, improve it on every platform. This "special feature" is exactly the kind of crap NVIDIA pulls with their OpenGL extensions. It works faster/it looks better but now you put the weight on the programmer: either figure out a way to work with and without the "special feature" or tell the player to get himself an NVIDIA card. Fuck it! I don't want to! I choose not to support a company that doesn't support me as a customer. All I want to do is spend US$40 on some stupid game, but the game won't run with my hardware. Well, bad luck, I'm not as happy, move on. Problem is, the day will come when every bloody game I'd like to run will be calling for the bloody card. And why? Because some greedy company not only designed an extension but put a patent on it. That is to say, some greedy company took away from me exactly what makes OpenGL a good thing: it's a well specified standard; it's vendor independent; it the back of your skull doesn't hurt when you read a program that uses it; but more important, it's extensible in such a way that a vendor is free to implement any given extension. That is, if there isn't a patent arround it.
So, no. You don't need to take DirectX and extend it in such a way that your "version" appeals to developers better than Microsoft's "version". If screwing people over is what is takes to make Linux "better", then screw Linux! Free Software is not about getting more people to use it, it's about helping to make better software for people who are willing to help along. It's about giving people the freedom to improve on the software people willingly use. It's not about screwing with some company to force others to move to my camp. If I wanted to do that I'd be writing non-free software to aid people at robbing with the click of a button.
A lot of people are going to complain that if DirectX ever works well in linux, it's hurting linux. Really though, if we take [legally] what's around to take from DirectX, we could essentially use the work Microsoft has done (not all of DirectX is horrible, a lot of games look good). Then we could maybe even add on to it and make it an new open programming interface. I dunno, just some thoughts.
Your Momma's so fat she makes emacs look like nano!
And you use Linux? LOL.
:)
FreeBSD actually -- I paid for my futzing only once
This is insane. DirectX games currently run by the hair of their chinny-chin-chin, can you imagine the horror when yet *another* abstraction layer is added? And can you imagine the dark clouds over the game companies' tech support when they read "Yeah I'm running under Win 98.. i mean.. well, Linux, really..."
Actually, crappy, complicated installation is one of the reasons I don't buy so many PC games anymore. I just don't have time to futz with video drivers, patches, etc. People used to rag DOS games for being incompatible with hardware... have you checked out the README for a Windows game lately?
Bull.
Try building a house with that attitude. "The foundation is not important. The color we paint the bedroom walls is."
I think if you asked the mythical "average user" to choose between these systems:
I think a large number of "average users" would pick system B.
Tom Swiss | the infamous tms | http://www.infamous.net/
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Hell, no! If you are going to improve on DirectX, improve it on every platform. This "special feature" is exactly the kind of crap NVIDIA pulls with their OpenGL extensions.
>>>>>>>>>>
Hey, don't blame this on NVIDIA. ATI does it too. The reason they have to do this is because OpenGL doesn't implement any cool features in the core API. Because Microsoft works with vendors to release a new version of DirectX every year or so, it supports the latest technologies. Meanwhile, it takes up to 6 months after a feature becomes common in hardware for it to show up as a standard OpenGL extension. If you don't like this state of affairs, go kick the ARB in the ass and ask them to improve OpenGL rather than blame NVIDIA, who is simply trying to work past OpenGL's limitations.
A deep unwavering belief is a sure sign you're missing something...
I've looked at SDL before, and I just looked at the site for Allegro. Neither of them is in the same league as DirectX. Just read the docs for each. There is so much that SDL and Allegro just don't do.
A deep unwavering belief is a sure sign you're missing something...
Then howcome the OpenGL implementation I use lists some non-trivial ammount of non ARB non EXT extensions? But don't take my word for it:
>>>>>>>>>>>>>
So does mine. My NVIDIA card lists a whole bunch of NV extensions. ATI cards list a whole bunch of ATI-specific extensions.
The fact that the extension is called GL_NV_foo doesn't mean, alone, that it can't be implemented by other vendors.
>>>>>>>>>>
But it does mean that vendors aren't FORCED to implement a particular extension. Say DirectX 8.0 adds vertex shader support. Since NVIDIA cards have vertex shaders, they implement this part of the API. ATI comes along with a card that features vertex shaders, and thus they implement the API too. Now, a game developer can just write to the DirectX API, and every piece of hardware that implements that API (ie. every piece of hardware that has vertex shaders; it would be stupid to have the feature and not expose it) gets accelerated. The OpenGL version of this story is different. NVIDIA releases the GeForce3 with NV_vertex_shader extensions. ATI comes along, can't use the existing extension, and makes its own ATI_vertex_shader extension. Now a game developer must detect each extension, and adjust his code path appropriatly. The burden of supporting different harware shifts from the hardware makers themselves, to the game developer. The API's integrity is weakened, and consumers who have cards that support a feature, but aren't popular enough for the game developers to code for, lose out. The world comes to an end. This could easily have been averted if
A) The ARB would release another version of OpenGL that supports these features. This is the optimal method because it allows these features to be more well-integrated. This is especially important for something like vertex or pixel shaders, because they fundementally change the 3D pipeline. And before you say that it would lead to uncontrolled releases, take a look at how MS does it. They talk to game developers and ask what features they want. They talk to hardware manufacturers and ask what features they're working on. They combine this input and come up with a new API every year or so. MS does a lot of things wrong, but this ain't one of them.
B) The ARB does the same MS-type going around, and implements standard extensions before hardware manufacturers get around to releasing their own. Thus, the ARB_vertex_shader extension would be out, and both ATI and NVIDIA would use it.
In fact, other vendors are encouraged to implement those extensions. The problem is they can not do it without entering into an IP problem. You can get a license and blah blah blah, but that's not the point. The point is why is there are patent in the first place? Afraid someone comes up with a better idea, uh?
>>>>>>>>>>>>>>>
Company's are like that. You can't do ivory-tower design, you have to adapt to how people work and think. The ARB's system doesn't do that.
OpenGL has to be extended... funny, that sounds awfully like extensions to me, doesn't it? The one thing you can't do with extensions is changing the order of the pipeline. Your triangles will be transformed before they are discarded by a depth test. You can turn things on and off, but you can't change the order of the pipeline. Other than that, you are pretty much free to do whatever you want.
>>>>>>>>>>>
You don't understand. Stuff like vertex shaders DO change the order of the pipeline! The move vertecies through a set of mathematical experession before sending them to be rasterized. I suppose this could be crudely emulated through the transform matrix, but with that you lose a lot of the features of vertex shading (such as the ability to filter verticies and implement different transforms on them). Also, it hides the uploading of experessions to the shader, which would kill performance. As for your comment about extensions, you miss the point. Extensions (for most cases) can do the job. The problem is that extensions are not standard parts of the API. This fragments the API (you *NIX guys call it diversity) and gives developers and consumers headaches. Like I said, if the ARB would be proactive in implementing ARB or EXT extensions, or if the ARB would be more frequent with its OpenGL releases, and implement these features into new releases, OpenGL could keep up, feature-wise, with DirectX. With the state of affairs as it is, it simply can't.
A deep unwavering belief is a sure sign you're missing something...
What you are saying is that it's good to have an API that "gets fixed" every year.
>>>>>>>>>
In that statement you show your grognard roots. It doesn't get "fixed" every year, its been great since 6.0. It evolves every year. It supports new features and technologies that didn't exist the year before. NVIDIA's product generation is one year, with a refresh cycle every six months. If the API cannot keep up with the pace setter of the graphics industry (and OpenGL can't) then it has some problems in its development model that need to be addressed.
Wow. That's a good thing?
>>>>>>>>>>
Yes, support for new features and new hardware IS a good thing.
With DirectX (and in particular, with Direct3D) that's doable. Why? There's one implementation.
>>>>>>>>
That's false. With DirectX 8.0, drivers are nearly as full an implementation as an OpenGL one. Read the article in MaximumPC magazine with the Matrox driver engineers (might be floating around on the 'net too.) It tells how OpenGL and DirectX drivers compare in terms of implementation complexity. Besides, that doesn't make a difference. In DirectX there is *one* API that manufacturers are forced to code for. ATI's driver, NVIDIA's driver, Matrox's driver, all of them use the same exact API. All of them expose vertex skinning through the same calls, pixel shading through the same calls, low-level resource management through the same calls. OpenGL doesn't have *one* API. Each card is allowed to expose major features through extensions. That's a *bad* thing. That means a game developer can't rely on all hardware being the same (as one can with DirectX) but must look at specific models. DirectX is a capabilities-based system. The game developer looks to see if the card supports vertex-skinning. If it does, it uses a standard vertex skinning API. This is a *good* thing. OpenGL's extension mechanism is manfacturer based. The game developer looks to see if a card supports a particular extension and uses that. Because of this, you end up with a game that supports hardware vertex-skinning running on a card that supports hardware vertex-skinning that doesn't run accelerated because the card's manufacturer wasn't important enough for the game developer to pay attention to. Unless OpenGL supports these features in the core standard (or releases ARB extensions quickly so manfacturers don't invent their own) then this situation will continue to hurt the consumer. Look, extensions for consumer-level API's is a bad idea. Microsoft tried to make DirectX extendible because it makes their job easier. They got rejected because game-developers hated extensions; it is too much a pain in the ass for them to deal with them.
DirectX is not a standard.
>>>>>>>>
Programatically, DirectX IS a standard. If I'm running a DirectX 8.0 complient system, there are a set of API calls and services that I can count on being available. In this respect, it is OpenGL that is not a standard. If I'm running DirectX 8.0 and it says that hardware-vertex skinning is available, I can just go use the standard API for it. Under OpenGL, I have to use non-standard vendor-specific APIs to access this functionality. Again, extensions were a good idea when only one or two were needed on a given implementation. Now, with over a dozen extensions for a given card, it is hard to call OpenGL a "true" standard.
No, it doesn't. It adds stages to the pipeline. You can still do traditional T&L with DX8.
>>>>>>>>>
Yea, you can, but why buy a card with vertex shaders if you can't make full use of them? Without several extensions, OpenGL *can't* make full use of vertex shaders, and the extensions vendors will come up with to allow OpenGL to do so will be propriatory and card specific. That means that OpenGL games will be behind the curve in supporting the latest features and that unless you buy from NVIDIA, it is likely that your're hardware will expose extensions that game developers didn't code for. OpenGL wasn't meant for the consumer graphics industry, it was meant for the pro graphics industry. In that industry, companies come up with majorly different hardware every half decade or so, and it is acceptable to only make new OpenGL releases every several years, with extensions filling in small additions inbetween. In the consumer graphics industry, however, major changes come every year, or even sooner if vendors' schedules overlap. In that market, it is not acceptable to only release new versions every several years. OpenGL is trying to adapt to the quickly changing market by using extensions to implement major functionality. Extensions just weren't designed to do that. If you want to take full advantage of an NVIDIA card, you have to code specifically for well over a dozen extensions. At that point, you're so close to writing card-specific code, that OpenGL can't be called a "standard."
And, BTW, you assume I have an NVIDIA card. I don't. The OpenGL implementation I use just happens to
support some GL_NV extensions. It's a very different thing.
>>>>>>>>>>>
It might support some GL_NV extensions, but those are ones that are well-established (read: old). I can guarentee you that it doesn't support any of NVIDIA's new extensions. The fact remains, that extensions are rarely implemented across the industry. Expecting manufacturers to use other company's extensions is like expecting them to use a consistant hardware standard without being forced too. Its just not realistic. At the end of the day, if you're a game developer, you have two options. You can go with OpenGL, and get the support of alternative OSs (whoop de doo), and then deal with supporting dozens of different extensions, or you could go with Direct3D, lose the alternative OS support, and lose the headache of supporting vendor specific code. If you're a consumer, you can buy an OpenGL game (which is the only option for alternative OS users) and live with the fact that you're PowerVR card will have a bunch of unsupported features, or buy a DirectX game and be assured that you're experience will only be limited by the quality of your drivers, not how big-name your card manufacturer is.
A deep unwavering belief is a sure sign you're missing something...
First, with you're hypothetical case, you're wrong. The driver writer doesn't have to implement this in software, he just returns a capabilities structure without support for this feature. Since Direct3D interfaces are immutable, old games won't notice this change, and new games will simply detect the lack of the feature and compensate accordingly. Sure it requires two cases, but it requires ONLY two cases. In the same situation, OpenGL requires a *minimum* of two cases.
In reference to extensions, you miss my point. You are equating extensions with features. That's not right. Extensions, in the real world, are one implementation of a feature. OpenGL requires you to support each extension seperately, even if they refer to the same feature. Let's try a concrete example. NVIDIA has an extension called GL_NV_fog_distance. Its functionality is not supported by any of the GL_EXT extensions, so a game developer uses this extension directly. Let's say ATI releases a new card that also supports the functionality of GL_NV_fog_distance. Since they won't (and probably can't) use NV's extension, they go ahead and make their own GL_ATI_fog_distance extension. Then Matrox comes along. There still isn't a GL_EXT_fog_distance, so they make their own GL_MATROX_fog_distance extension. Now, you the hapless game developer must support each of the three extensions seperately, plus handle the no hardware support case. If you were a DirectX developer, you would only have to handle two cases, the hardware supported, and hardware unsupported case. Now lets say this game ships, with support for the three major extensions. Now, PowerVR releases the Kyro II, with its own GL_PVR_fog_distance extension. Now you, the game owner, own this game and a Kyro II. With OpenGL, you have to wait for the game developer to patch his product, or live without support for this feature in your game, even though your hardware supports it. If you were using DirectX, PowerVR would have implemented support for the IDirect3D8->FogDistance() function, and you're game would have automatically taken advantage of it, no matter which card you used. Think of DirectX features as mandatory OpenGL extensions. HW makers either implement the DirectX API calls for a feature, or don't expose the feature at all. That allows all games to use the DirectX API, and assume that any supported features will be exposed through this single set of calls.
...
Somewhat different to this fictive "uniform hardware" you imply DirectX supports.
>>>>>>
You have to make the difference between an extensions and a feature. If a DirectX card doesn't support a feature, it will simply return a capabilities structure that says that feature is unavailable. If it *does* support the feature, then the app can use the standard API without worrying about what card the feature is implemented on. In OpenGL, the game not only has to be concerned about whether the feature is supported, but has to worry about how the vendor chose to expose that feature. Again, its a matter of two codepaths (which will always be present as long as hardware supports different features) or a minimum of two code paths (which isn't necessary if all implementations of a feature are forced to use the same API to access that feature, as is required with DirectX).
BTW, wouldn't you prefer a good game of chess?
A deep unwavering belief is a sure sign you're missing something...
...but it would be EVEN BETTER with some of the additional breadth and quality of closed apps out there.
I don't know if that was a cleverly hidden flaimbait or not, but I'll assume it wasn't because for the most part agree.
One of my biggest problems with much of the "Free" software that everybody seems to love so much is that the greater majority of it is worth every penny of the price.
This is esspecially true of games. While there might be one or two high quality free games that accidently slips out once in a while, there aren't a lot of really interesting free projects going about. A handful at best.
Every now and then something really cool does pop up -- but progress on such projects moves really slowly and you sometimes wish those free projects would get funding and go commercial just so you'd have a better chance of seeing the project completed.
Once again, I'm not saying free software is bad -- I LOVE free things -- but I'll pay $50 for a good solid game before I'll even think about wasting time downloading 5 stupid Tetris or Boulderdash clones.
"Everything you know is wrong. (And stupid.)"
"Everything you know is wrong. (And stupid.)"
Moderation Totals: Wrong=2, Stupid=3, Total=5.
WINE sure sounds like emulation to me.
Very strictly, yes.
But considering how most traditional emulation is being done, some would argue that WINE better closely compares to a "Wrapper".
Besides, as the title says, "Wine Is Not Emulation".
"Everything you know is wrong. (And stupid.)"
"Everything you know is wrong. (And stupid.)"
Moderation Totals: Wrong=2, Stupid=3, Total=5.
Luckily, nobody FORCES me to buy software.
I could use crappy free alternatives, or I could make a mistake and buy crappy commercial. But in the end some of the best software for any given task could be on either side of that line, but what you'll normally find is that anything worth paying for has a price tag on it.
I don't complain when I have to shell out some cash for good software, nor do I complain when free software blows. I just don't use it.
Luckily, in some ways, I still have some choices.
"Everything you know is wrong. (And stupid.)"
"Everything you know is wrong. (And stupid.)"
Moderation Totals: Wrong=2, Stupid=3, Total=5.
You'll have to purchase this emulator. What's the difference (and by the way, I was advocating piracy)
Someone you trust is one of us.
Yeah, fuck directX! We don't need an implementation of it! While we're at it, we don't need an implementation of Appletalk or SMB either! And an implementation of the X Windows API? Who wants that? It's bad news because it'll make people program for that instead of our own API! And while we're at it, let's just get rid of our standard C API all together and write our own! Yeah! Fuck DirectX! Who would want an implementation of that!?!
"I may not have morals, but I have standards."
"I may not have morals, but I have standards."
...to push game programmers not to use DirectX in the first place? Stick to open standards and you can port the games to just about anything.
They already have a patch to wine that I tried quite some time ago. The American McGee Alice demo works just as well under Linux as Windows. (Unfortunately on both systems it crashes.) I haven't tried any other games, but they already have a bit of work done, so I wouldn't call it vaporware.
Let's see what's bull. If you look at the extensions carefully, you'll see NV in their names. There is a reason to it - the extensions are NVIDIA-specific. Only patent-free extensions have gone into the ARB extensions - and they are for all to implement.
OpenGL is a low-level API but not a touch-the-metal API. The NV extensions is so close to the chip it is almost not possible to port it to another chip.
Get the idea?
About your claim that "core OpenGL doesn't have to be changed in order to support new hardware features" - how about...vertex skinning? These usually requires *quite* some code if the extensions aren't there. Are you expecting the driver to recognize this and that sequence of calls as "ah, so the code is trying to do vertex skinning!!"?
Drivers aren't that smart yet. And if you want to develop your driver fast, you don't want to put AI code in it to have certain series of calls recognized. So, OpenGL -->**HAS**-- to be extended to support most new hardware features.
So, he's correct. If you want cool features, push the ARB a bit. Only if I know how to do this...
Games are basically the only reason to still use Windoze
I like some aspects of linux, but I can name several reasons folks still use Windows. User-ease, for one. Microsoft Office (or Corel, i suppose) is another.
I don't want to start an argument here, but I'd like to point out that there are other reasons for the average user to use Windows.
-J
Karma: T-rexcellent.
Another abstract reference to the "average user". :)
Yep.
"I think it's fair to say that the only reason folks still use windows is because they've invested so much time in figuring out the totally convoluted way to do simple things"
I don't think it's so much that as people just being comfortable with Microsoft apps (I'm constantly surprised at the steep learning curve I see people experiencing even when learnign new word processors, even though the basic concept is the same). Yes, Microsoft has a monopoly. Does that, in itself, make their OS bad? I really don't think so. Now, Windows isn't the greatest thing out there, but somestimes it's all you need.
I totally agree with you on the point of dumbing-down the OS. The screenshots I've seen of the next major Windows version are frightening in their apparent simplicity (big shiny buttons! whee!).
-J
Karma: T-rexcellent.
--
Free Software: Like love, it grows best when given away.
I'm using an ATI TV-Wonder - I like the ability (in the software) to save sequencial (I'm sure that's misspelled) files (like image000.jpg, image001.jpg...). I'll look up XawTV and the Hauppage item - sounds very interesting.
John "Dark Paladin" Hummel
52 Weeks, 52 Religions with John Hummel
Dang, I hope this works. I have two computers in my house - a Pentium 450, running GNU/Linux, and a Pentium-800 running Windows 98 - and the only reason why the Win98 box is in my house is for my game reviews/walkthroughs.
Naturally, there's some hurdles to overcome, like speed optimizations, working through the entire DirectX system and making sure things work the same without Microsoft getting pissed off and trying to sue people for some sort of copyright violation (which is a good reason for these folks to work with the Wine project).
I know some folks are skeptical, but I honestly believe that games are a major issue (not the biggest - user friendly-ness for Bob User and software compatibility, the reason why Macs don't sell as well as Windows, IMHO) for Linux, or any operating systems acceptance, on the desktop.
With great game support (and when when I see some easy-to-use TV-card support for Linux so I can do my console walkthrough stuff), I won't ever have to run Windows again. (And, at the rate that Windows ME and Windows XP are becoming game unfriendly, at least in performance compared to Win98, I can't wait to ditch them).
Of course, I could be wrong.
John "Dark Paladin" Hummel
52 Weeks, 52 Religions with John Hummel
There are plenty of directx games. I'd love to be able to play aoe2 under linux. I'd finally be able to get rid of crappy ms software for good. err...
Need a website host? Try out http://WebQualityHost.net
Actually, I kinda wish somebody would implement something like DirectX for Linux
Have you ever tried coding in SDL? It's a cross-platform 2D game library with graphics, input, and sound support.
What about Allegro? It's another cross-platform 2D game library, used by scores of free games such as Tetanus On Drugs. It also has a 3D addon that uses your platform's existing OpenGL support.
Will I retire or break 10K?
No i mean running comsole games on as native x86 code.
You may have meant that (in the sense of xbox), but you said "gamecube" which is not x86 based in the slightest; it's actually built around a highly-customized PowerPC processor. Besides, how are you going to read GCN game media, which are not CD or DVD?
Most new emulators use a dynamic recompilation core anyway, to cache emulated instructions as native x86 code. (It's the same technique Pentium 4 implements in hardware.)
Will I retire or break 10K?
If all we need is running games on linux, why don't we emulate consoles?
TuxNES, DGen, and SNES9x (both available from Zophar's Domain) are console emulators ported to GNU/Linux + X11. Those consoles are from back in the day when games were games and not merely interactive movies. Want shooters? Lifeforce for NES and Zero Wing for Genesis are still as fun as it was when it was first released (and still more fun than modern shooters such as Q3A/UT/Tribes). And yes, software is still being developed for NES.
Will I retire or break 10K?
There is also Windows 2000, which runs all Windows programs better than anything else mentioned in this thread!
Assume that I (and perhaps other users connected to my system) want to run apps designed for working POSIX-compatible systems (not NT's bastardized "POSIX" subsystem) while I'm running Win32 apps. Assume further that I have already forked over three months' wages ($300) for Windows 2000. Apparent choices include
Will I retire or break 10K?
absolute waste of time...linux needs OGL extensions to keep pace with (or surpass dx) as well as quality dev tools and other game apis.
to follow windows, as wine and this project are doing, does nothing but dilute efforts and establish windows and microsoft as the standard.
what a awful waste of time. wine has been around for ages, and will never be able to keep up with redmond's maonkeyshines.
what more evidence to you need? my god, just go clone java in c++ -- the multimedia apis -- you'll be doing linux a much greater favor.
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
Until someone begins making games for Linux that do not exist in the Windows world, Linux will forever be in the shadow of Windows. Once you see people begging for a certain Linux game to be ported to Windows, then you've got a hit. This will never happen unless all of Linux is dumbed down enough that people will be able to concentrate on doing things other than administration or tweaking of their box. At that point it will just have a little penguin bootup screen and an uncountable number of bugs as it asks "where do you want to go today?".
Linux is becoming more and more a Windows clone everyday because even the folks that advocate it cannot think of making it anything else. It will look and feel just like it and at that point, what will be the point?
That's my opinion of Linux on the desktop. My opinion of the server end is, don't you ever show me a Windows box and tell me that you want to put something critical on it. It has to be either Solaris or Linux.
"Beware of he who would deny you access to information, for in his heart, he dreams himself your master."
I've made a half-way transition to Linux twice, but always ended up coming back to Windows. And both times the reason was some incredible game that I got hooked on.
I hate owning a system where I can't change *exactly* what I want when I want. I hate owning a system that crashes for inexplicable reasons.
But, in the end, it's the games that bring me back. I can word-process, create presentations, analyze data, etc. in both Windows and Linux. But if I want to unwind with a fun game of Tribes or somesuch, I have to turn to Windows.
---
4-star general in a one-man army.
True, but Linux users like their games. For many of them, it's the only reason to still dual-boot. Heck, why do you think Loki games is alive?
I can't be karma whoring - I've already hit 50!
SIG: HUP
I finally was able to break the shackles of Intel by finally going AMD/VIA. Now I'd like to have a Wintel box without the Win or Tel parts in it. Yeah, I can set up a dual boot, but, heck, I'm lazy. I'd rather not have to worry about what to boot into today. The fact is that most people out there are like me in this aspect rather than most of the serious gearheads that populate /., people who aren't able or just don't want to make the effort.
Linux is a niche OS in good part due to games. The majority of games out are for Win (and unlike most people, I haven't had bad performance on ME with games, for some reason). It's a good shortcut into the market. Any project that can do this has my support, and should have the support of every Linux user or wanna-use-but-what-about types.
When I migrated over from Amiga to the Wintel world, I slapped OS/2 on my first few boxen. Loved that damn thing. Bitch to configure, especially for a relative novice, but once it was, it seriously beat Windows all to hell. I only got rid of it when everything started to be made for Win95. There have been a few posts wondering if a game layer for Linux would set up an OS/2 situation. I don't particularly think so. We're only dealing with emulating DirectX, not emulating the entire operating system like OS/2 did. A project like this is less dangerous to Linux than the emulation layer in Mac OSX will be to the production of future Mac apps.
If using Linux is about choice, how come people complain when I choose to use Windows?
GPL is great, especially for OSs for security reasons, but I urge people to embrace closed, commercial Linux software - there's a lot of great stuff out there that will never be GPL'd. To be perfectly clear for the flame-proned, GPL is great, free software is great, Linux is great, but it would be EVEN BETTER with some of the additional breadth and quality of closed apps out there.
+5:offtopic,but anti-American
Potentially, all this is going to do is discourage gaming companies from making any changes to their game code, because they won't have to actually port anything. This keeps control in the hands of Microsoft with their DirectX API, and even further discourages the use of Mesa or OpenGL.
"OpenGL? Sure, we COULD'VE used it, but heck, even Linux is mostly an OpenGL platform and THEY are buying DirectX games."
And while normally I'd say that competition is a good thing, alternatives aren't exactly being talked about much in Slashdot articles. Compared to DirectX and wine, you don't hear much about the SDL on Slashdot.
What's keeping Microsoft in the driver's seat isn't so much the quality of their software, it's their hold on proprietary APIs and file formats. Sometimes I think all this is going to do is strengthen that. It'll benefit existing companies first and foremost, consumers who want DirectX games second, and efforts like SDL not at all.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
Everyone I know who is a windows advocate is so because of gaming. The majority of all games are not ported to Linux, and therefore, if you are a heavy gamer, you almost need Windows. Not that I am against windows (Because of my job and it's excess of NT workstations, I've become used to it), I am just for Linux. But getting to my point.... Finally there are no longer going to be arguments that Windows has something over Linux.
The framerates on most games are equal to the Windows versions, and in some cases actually higher. Alice is an exception because it uses an astronomical number of mutexes. There are literally tens of thousands of locks per frame. TransGaming is working on a solution for this but it will require an overhaul of Wine's mutex handling.
2) TransGaming's patches are not pay-only. The patches are and will always be free. Subscribers simply get to vote on what is the next priority game to get working, and it is a way to donate money directly to the project
Actually, TransGaming has already integrated their DirectDraw patches back into the Wine cvs tree. With the latest release of Wine and the TransGaming patches, I can run Starcraft, Halflife, Diablo II (cracked to remove incompatible copy protection), and Alice. That's hardly vaporware. They've made huge progress in only a few months.
Alice is based on the Quake III engine, meaning it uses OpenGL for the graphics API, not Direct3D. It does use some of DirectX (DirectSound, DirectInput), but I'm fairly sure even these parts can fall back to waveOut and standard Windows input routines..which Wine probably already covers out of the box...So, while I don't think this thing is completely vapor, seeing Alice running on it may not be the greatest test of its ability to provide DirectX compatability on Linux...
About time. The task of implementing DirectX on top of native interfaces will be a moderately difficult task, but with proper funding not impossible.
What I find interesting is the buisness model. Subscription based services seem to be the only model that works, and hopefully we'll see movement in that direction to really push some of the open source projects ahead.
Cool. Games are basically the only reason to still use Windoze. If new users could bring their favorite games to Linux, it would remove the main reason peeps are scared. I'm looking forward to not having to have dual-boot to get my gaming on.
This sig may be reproduced by anyone for any reason.
It would drag performance to it's knees. On a p3 500 mhz machine with 380 megs of memory windows runs in vmware like a pentium 100. I couldn't even imagine how terrible hardware acceleration would be in a VM. It's perfect for running some low overhead business apps but there is a reason vmware is on release 2 and has *NO* support for either directx and dvd playback.
Good thinking there turbo, the entire AoE Series is sold by Microsoft.
Trying is the First Step to Failing --Homer Simpson
There are several problems with VMWare (and projects like it, such as the really cool and free Plex86) that make it unsuitable as a gaming platform.
First of all, and possibly most important, VMWare doesn't support DirectX, making it useless for the vast majority of Windows games. I don't know if this is because the VMWare developers don't care about games, or if it's actually not possible to run DirectX in VMWare (it may not be possible for technical reasons, and 3D accelerator cards may not be possible to use either).
Second, because of the method of emulation used, VMWare and projects like it will always be slower than natively running the code.
Third, VMWare requires a copy of Windows in order to run Windows. TransGaming's free DirectX implementation, along with WINE, completely eliminates the need to buy Windows. This isn't really a problem now, because everyone has Windows, but maybe in the future...
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
That pinball game that comes with Win2K is kind of cool, though.
Slashdot: Open Source, Closed Minds.
One way to handle this would be to pull a Microsoft on Microsoft. Emulate (embrace) DirectX and then extend its functionality in a way that appeals to game developers. Perhaps some easy to use calls that tie more directly into Linux, for improved speed. Developers still get to code to only one API, but they also have an opportunity to use one or two "special" calls to improve performance under Linux.
Over the course of time, as more and more of these special functions are added, developers will find that they are doing more and more stuff that is specific to Linux. Not because they have to, but because it improves performance and gives them a higher framerate in the Linux benchmarks.
In the fullness of time, they might find themselves stepping entirely away from DirectX on Linux and moving to the GNU DirectLinux API. Purely for performance reasons, of course, and because they've already got enough Linux-specific code that this is just one more small step.
From there it's only a short step to coding a port entirely for Linux.
Companies are notoriously short sighted. Appealing to them to make a radical change because it will benefit them in the long term is a pointless endeavor. Instead, give them 50 small changes, each with definite short term benefits, that when taken together arrive at the same place as the one radical change.