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."
OS/2 never really had that large of a following, although early on it had a lot of hype which did generate some native applications, most of which were dropped in favor of Windows 3.x.
Don't confuse vocal supporters for a market. (Certain game companies made that same mistake with Linux...)
The actual Linux Game Market consists only of those individual who do not currently purchase Win32 games, who refuse to dual boot or run under emulation.
The mythical Linux Game Market includes those individuals who are already buying Win32 games and are running them via dual boot or Win32/DirectX emulation. The Linux game market largely overlaps the Win32 game market, there are few new customers. A Linux version of a game will generate few new sales, it will primarily replace Win32 sales with Linux sales.
In computer programming and hardware development, there are two ways to gain market share evolution or revolution.
evolution- this is a method of adapting your new technology to the old technology so that things are backwards compatible.
revolution- this is enacting entirely new standards, ones that are "better" than the old ones and can do new and exciting things.
Traditionally, when firms use a backwards compatible structure, or include other firms standards into their own it is a sign of weakness. There is no surety that their new design will work as well, and they need to lean on other development companies or other hardware to support their platform. One of the firms will die. Guess which one usually will.
The problem is all of the tools the established firm has to battle the newcomer with. In this case Microsoft can change the API's of its DirectX architecture to disallow the emulators to work on new games. I hate to say it, but Linux usually takes a long time to catch up with new hardware and software developments in the windows world.
The thing I would like to see more of it open source programming for Windows platforms. This might be the direct result of a good windows emulator on Linux too. Imagine a world where the dominant platform was open source, and most of the games published came with source code. The ease of adaptibility would be great. A few tweaks (sometimes more, heh) to the games code and it could be run on another platform. But there might not be any need. A windows that was as customizable as linux, sweet.
This all relies on Microsoft opening its code of course and is unlikely, if not downright impossible. But I could see a future where games programmed for windows came with the source code to entice those of us who use linux to purchase the program.
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.
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.
You are correct here, but we need to remember that OS/2 was not open source, and was controlled entirely by a corporate entity, being IBM. OS/2 was in direct competition with Microsoft, and it being a better operating system (in my opinion), it never achieved the user base that Linux does now. Linux also isn't in direct competition with anything.
This is a great thing to happen for Linux because people will still write nice games natively for unix-like operating systems, and large corporations will still write nice games for Windows only, that will soon be able to run on Linux.
Fuck Ajit Pai
I believe he meant to make a mach personality out of wine so you can have a concurrent wine session that's just as low-level as windows, and is compartmentalized from the unix kernel.
WWJD? JWRTFM!!!
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..."
So what you're saying is you didn't read the part of the article where he says they're going to be doing tech support along with the subscription-based game voting.
WWJD? JWRTFM!!!
According to the homepage, it's the Alladdin Free Software License, which is not considered Open Source if you follow the OS definition.
Essentially, they want to get paid if someone makes money with their software.
Sebastian
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.
how do you get multiplay?
Meaning all multiplay are the same time.
Koules are not stupid!
Seriously though, a netplay koules would be right up there with snipe. How do you get it to put many players in the same rink?
~^~~^~^^~~^
I use one too, but I get fuzzy lines and waves going across the image. Maybe I put it too close to the network or video card.
~^~~^~^^~~^
Except that quite a few of those pedestrian user types are more than adequately entertained by crappy rip-offs of 10-15 year old games.
Way to ignore the ACTUAL needs of the user, Lemming.
A Pirate and a Puritan look the same on a balance sheet.
Red Alert 2 is specifically emulator hostile.
Will it even run under VPC?
A Pirate and a Puritan look the same on a balance sheet.
One can say the EXACT same thing about commercial games. You actually get to PAY for the priveledge of being put into the same situation. Sure, there are a few imaginative or innovative commercial games. However, most are ripoffs of each other with the number of genres actually dwindling.
Depending on your tastes, "doing it yourself" may be the only way to go.
A Pirate and a Puritan look the same on a balance sheet.
Whether or not you "have to buy it or not" does not alter the fact that much of the shrinkwrap that you are bragging about is total crap.
Quite often, what is not worth putting in a landfill also has a pricetag on it.
OTOH, the duration of a full development cycle for commercial software has yet to pass since
serious consumer/novice awareness of Linux began.
In those areas where commercial software doesn't have a headstart in terms of decades, the you attempt to draw isn't quite so obvious.
Also, one is quite often "forced" to keep it once you've done what is truely necessary to determine whether or not it's really crap. Not only that, but software Robber Barons are conspiring to make sure that you are forever stripped of the legal right to return shoddy software.
They seek to codify the state of things which came about through consumer apathy and ignorance of the law.
A Pirate and a Puritan look the same on a balance sheet.
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.
Done right, this could be a great way for people :)
to get the stability of Linux along with the stuff
that's not yet getting any porting money.
What part of "A well regulated militia" do you not understand?
In case you didn't know, tribes is available for linux,too. Check http://www.lokigames.com
And this games stuff, well I played Diablo2 until the end. Under Linux. With wine. Took some fiddling to get it to run, but now it workls just fine.
--
Moritz
If you want to help Gimp be a replacement for photoshop, then you should contact the developers of Gimp and tell them what you think still makes you use photoshop over Gimp. I think that they would be very interested in that, as it is obviously one of the goals of Gimp to replace photoshop with a fast, stable, powerful, and free program which supports the same features.
Part of open source development depends on you -- the user!
I don't make the rules. I just make fun of them.
Welcome to the world of file permissions, love bug.
What TV card do you use? I've got a Hauppage WinTV Go, and XawTV loves it.
http://www.strusel007.de/linux/xawtv/ is the XawTV homepage. It's a nice, basic X application, updated quite often nowadays. 3.41 was just released a few hours ago.
WinTV Go cards (PCI, BTW) works by using the BTTV kernel driver. I really don't recommend the WinTV Go, though. It's one of Hauppage's oldest models and doesn't have much in the way of features, not even stereo sound, and has a 7?? x 5?? maximum resolution; I don't recall exactly what it is. On the other hand, it's dirt cheap compared to a recent stuff. I got mine for $60 canadian.
I don't know anything about how well newer cards are supported. The BTTV driver supports all cards using the BT8x8 chipset, though. Sorry for the rambling reply.
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.
That's bull. The core OpenGL doesn't have to be changed in order to support new hardware features. The OpenGL extension mechanism is perfectly capable of exposing the features in a portable way. It is not necessary for OpenGL to go arround chaning the pipeline every other release. And I'm complaining about the fact that other vendors can't implement certain registered extensions because the vendor has patents covering them.
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:
The fact that the extension is called GL_NV_foo doesn't mean, alone, that it can't be implemented by other vendors. 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?
Well, duh! That's the whole point, isn't it? You don't want this to be implemented in software, do you?
Of course not. Why would I want to do such a thing if there are proper ways to do it?
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.
I won't address all the points you mention because you managed to hit the crux of the issue and you don't even realize it:
What you are saying is that it's good to have an API that "gets fixed" every year. Wow. That's a good thing? With DirectX (and in particular, with Direct3D) that's doable. Why? There's one implementation. DirectX is not a standard. The "standard" is the implementation du jour. And that implementation is done by one company. That company gets input from other companies, but they get to decide what DirectX is today. "Oops, that didn't work out as well as we expected... never mind, we can change it again". On the other hand, OpenGL is defined by a standard. You implement the standard. There's a sample implementation but you are not forced to use it. Brian Paul didn't, and his implementation does pretty well conformance-test-wise.
No, it doesn't. It adds stages to the pipeline. You can still do traditional T&L with DX8.
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.
What you are saying is basically that: a) Every now and then a new DirectX release comes out that supports new hardware features; b.1) vendors update their DirectX driver in order to accomodate the new release or or b.2) vendors don't update their drivers and leave users with drivers only for the previous release; c) developers rewrite their applications in order to take advantage of the new features this "uniform hardware" is exposing via DirectX. See the flaw already? If b.1 happens, and whatever prompted a really calls for an API revision/redesign, that driver is offering a software implementation of the "new features" of this "virtual hardware". Since the program is running painfully slow the developer has to offer a possibility to turn off the use of the spiffy feature, meaning, effectively, that he's anyways coding twice. One with, one without. But since we seem to be talking about games (you at least), the game is going to plain suck with that feature naively turned off, so the developer needs to offer either an alternative that doesn't look as good or isn't as fast but doesn't suck as bad as not having something there at all, or he chooses to slap a "Bloodsucker Company's Card required to run this" on the box. I don't even have to spell out what happens with b.2, I hope. At the end, how is that different from using OpenGL extensions, this vendor hell you are trying to depict?
Another point you mention is that the game developer has to see if the OpenGL implementation supports a particular extension. Yes, that's true. Implementations, unless they are software only implementations, normally don't list an extension as supported unless the extension is somehow implemented directly in hardware (instead of emulated in software, NVIDIA being a notable exception to this, listing support for 3D textures even if the hardware doesn't support that feature). That means, the developer can be somewhat sure that if he finds an extension, it's actually a hardware feature. Somewhat different to this fictive "uniform hardware" you imply DirectX supports.
BTW, wouldn't you prefer a good game of chess?
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.
why bother with pcs? (posted via DC -using joystick no less) =)
A 200Mhz MIPS is more than enough hw to write fast high poly count console games. PCs have the problem of various setups. That's why PC games might take a hit in the future vs consoles with hdds and internet play.
Wine has been going on for a long time and it still has a lot of little annoying problems with many applications because Win32 is such a big, inconsistent and poorly documented API.
Support for games may actually be easier because games tend to use a relatively small subset of the system API and mostly rely on their own coding skills rather than OS services. They like to directly control every pixel of the (full screen) display rather than rely on system widgets and standard dialogs. "Just give me access to the hardware and I'll do the rest". The DirectX API was designed to appeal to game designers by making a Windows box appear to be a DOS machine with nearly direct control of everything "What's this scheduler thing? too unpredictable. It will have to go. Message handlers? whaddya mean? gimme a polling API, that's how I did it on DOS."
-
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
Half-Life ran before, FYI.
Is this possible?
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!
I think your missing the point. DirectX was created because there already were too many layres of abstraction. It was very hard under vanilla win32 to directly access hardware. Now you can.
And i dont think that WineX is going to be an extra layre of abstraction, but rather another implementation of the same API.
my other penis is a vagina
That dosent even make sense. Win32 already had a built-in driver system.
my other penis is a vagina
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?
I imagine that that is the problem for trying to emulate games in general. You know a lot of games crash on the target OS, so clearly it's only going to be worse if you stick another layer of possible mistakes into the mix.
On the other hand, if games were written in a modular way, replacing the graphics/sound/input parts of it wouldn't be that terribly bad, especially cause OpenGL compiles well across platforms...
-S
No - they'll just take less time to develop and release new games.
--
--
Rare Window - free your photos
Start a business... say you bought a Compact and you want support :-)
nosig today
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
Well, that's nice and all, but we still need a way to get rid of the ia32 architecture if we truly want to have a choice. What we'd really need would be some sort of cross-assembler, so that we'd finally be able to move on to PPC, Alpha, or UltraSparc.
As we state on our website, TransGaming will not put efforts into WineX compatability for games that are already available as traditional ports from companies like Loki and tribsoft.
The problem is that we have a chicken and egg issue. Major developers won't take the Linux market seriously unless there are lots of games sold for Linux. But we don't see lots of Linux games being sold in part because the selection is too limited.
We hope that the work we're doing will help the Linux games market grow so that everyone will prosper!
-Gav
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.
Since windows aps are running on the same processor as windows aps, in a sense they ARE native aps since they are in the same machine language as linux aps. Where they differ are in file format (exe vs elf) and link libs. Consider all the different link libs currently used on linux. Some 'native' linux aps must be linked against GTK, some QT, others Motif, etc. Yet they are all considered native just because they are all contained in elf file format? Provide a binary loader for exe files, provide the required libs to replace the dlls and basicly your windows aps become native linux aps. Windows is nothing more than another gui that COULD run under linux. Extend and embrace, only this time it is the penguin doing it. Why not?
As far as I can tell, the only new tidbits of information contained in the article, are the use of SourceForge as their repository mechanism.
I tried the preview with Alice game demo, and was pleasantly suprised, but the frame rate was still sucko compared to under win98.
Its a shame that linux is still light years behind in game dev - I've got Revelator 3d glasses and i don't think the support for these will be coming anytime soon.....
This sort of cludge were is a complete waste of time.
Someone you trust is one of us.
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.
*yawn*
Another abstract reference to the "average user". The average user is a complete moron and is assimilated into Microsoft's hegemony. The "linux user" has no reason to use windows other than gaming.
You said you didn't want an argument. ok. I wont start one. But I would like to tell a story. I have a father. He is a lawyer. He uses windows and Corel Office. He has been using windows for the past 5 years. Now, I can tell you with 100% certainty that if he had to *start* again with no prior GUI experience, it would be just as easy for him to use linux as windows. I was at his office today reinstalling his windows operating system because the networking was unreliable and windows update refused to work. After waiting an hour for windows to install, I was telling him about linux. I told him that to install linux (in my case debian) the only time-intensive task is unzipping the actual program files, and for the base operating system, would only take 5 to 7 minutes. He seemed utterly amazed. Ok, so we got windows installed. But now we were faced with strange network behavior on a specific url. I knew this was strange and was a result of some misconfiguration. My dad asked why I couldn't fix it, and I told him that Mircosoft doesn't want me to know what's wrong. It's a closed proprietary OS that microsoft wants to keep dumbed-down. I told him that if it were linux and a specific url was no working, it would be simple and deterministic to figure out the problem. With windows such behavior is completely undocumented.
As it relates to the topic at hand, 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. oh, and games. Oh, and microsoft has a monopoly.
The folks over at Linux Tribes have managed to get Tribes running on WINE.
I'm not entirely sure how much hacking it takes to get it to work, but they say the stability is about the same as running Tribes under Windows (as in, Tribes will crash about the same amount whether being run in Windows or WINE).
Completely off-topic, one of the guys who runs LinuxTribes, Bad_CRC, is also one of the guys who helped make one of the "All your base" videos floating around.
Moller
Funny yet true. I set up my old computer for my parents and let them choose between Windows/Linux. The interesting part is that they use Windows for Internet (easier PPP) and reboot into Linux to play the games. Unbelievable how many games are shipped with (trying not to plug) some Linux distributions.
Ozwald
Hardware support/detection is another. And that one improves over time, moreso as the user base increases in size.
It's always interesting to me how divided the community is on this matter... I understand the purists would prefer effort to be done on making Linux specific apps; but on the other hand I know I don't run Linux on my machines purely because I have win32 apps that I must run, and if the price of that is running Win2K then so be it.
Remember that OS's are not important. Apps are.
~~~~~ BigLig2? You mean there's another one of me?
Not sure how that could impact performance, though.
There's 10 types of people in this world, those who understand binary and those who don't.
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...
So.....it is agreed :)
We shall embrace and extend - we see their API and raise it a dollar.
*leans over table* - I am glad we all agree - lets break for lunch.
btw: get wine together with SDL, and OpenGL: oh and press coverage is here: http://www.linuxgames.com/
Have fun hackers :)
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.
I do not know about the other games which I don't have, but Starcraft has already been working in Wine for a while before Transgaming came around.
All kings is mostly rapscallions. -Mark Twain, The Adventures of Huckleberry Finn
--
Free Software: Like love, it grows best when given away.
Now come on. You have to be more subtle if you want some flames.
IANAL or an expert on the GPL, but this would be an interesting test case.
Say we have this "improved" DirectX for GNU/Linux with specific calls that are in a GPL'ed library.
If it was found that say Age of Empires 3 was using such a call without being under the GPL would the community have a snowballs chance in hell of winning a court battle?
Read my plan to save the Bengals
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
+1 Astute
Need a website host? Try out http://WebQualityHost.net
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
Wine is not the way to go. Wine hasn't successfully ported crap. Please no flames, I'm serious. This is somewhat out of my areana, but isn't there a better way to go thatn WINE?
More race stuff in one place,
than any one place on the net.
Get a job with better pay
$1000 a year is all some people (namely, college students) are allowed to earn. Any money not earned through approved channels (Federal Work Study programs) is distributed thus: 50% taxes; 50% expected family contribution to tuition and fees at a private school.
Will I retire or break 10K?
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?
As it is, there just aren't that many people who use Linux at home yet. Try asking people like my parents, and they will just ask "why?". It's more stable, but in their eyes it's more difficult to use because they're used to Windows. If there was a way to run Windows games though, it would be another huge reason for them at least to try it. Until Linux has plenty of users, it's more profitable for the corporates to develop games for Windows. Therefore, this is a good way to keep gamers happy until Linux gets popular enough for native commercial games. Even better in my view, would be to use consoles. Okay so they're less customisable, but I much prefer shoving a DVD into my PS2 and playing the game straight off, to faffing about trying to get it to run on my unique PC hardware.
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.
So what is the license to thier code? Will we be tied to them for future improvments (like darwin)?
You mean koules is not a Linux game! :)
You must be joking...
If all we need is running games on linux, why don't we emulate consoles?
Until two years ago the only console available (with good games) was the PlayStation and there existed no emulator for Linux. Even freeware Windows emulators fade away.
The main problem with PlayStation emulators was they had to emulate too many thing (the CPU, the Memory [aka BigEndian], Video hardware, ROM, joystick, cdrom, etc, ...)
But the upcoming consoles (aka XBox) are more similar to the PC. So it may be more feasible to implement a Xbox (or gamecube) compatibility layer than implementing a windows compatiblity layer.
I'd love to get RA2 running in Linux. Red Alert 1 works well in Wine. I had trouble getting the Commandos series working because it wouldn't find the CD no matter what I tried. I rebooted to Windows and cracked it so it didn't need a CD and now they work great. I've been spending a lot of time in UT since I just got cable and ping time is great but I've been wanting to play RA2 again.
Well I believe that DVD's can't be correctly displayed on most linux boxen. It's the only reason to keep it up on my laptop
Your pain is funny
The combination of high school physics, 4 player multiplay (for the full effect, have three people on the keyboard and one poor bastard on the mouse), and ZeroWing style translation errors is astounding...
--
I can say right now that Tux Games stands against Emulators. While emulators could be good in the short term, and they would certainly give Tux Games a much wider variety of games to sell, and thus more profit, they will kill native Linux apps. Take Loki for example. They produce top quality games for Linux. But these games cost money to port, and they generally are sold for somewhat more than the windows versions (as they are released a little later). What chance would these games have if the windows versions could be bought for 30% less but only ran 10% slower. Loki and tribsoft and Hyperion would all go broke in a month!
Sure, it may be the quick fix, but in the long term it will hurt Linux more than it will help. And dont forget, Emulation only works till the next version comes out. Do we really want to sacrifice platform independance to the whims of microsoft not changing directX? I know I dont.
Tux Games. Your complete source for native Linux games.
If they (or another company) did this for applications other than games then I'd seriously consider subscribing. And it wouldn't have to be limitted to programming, people could document or translate too.
The dowside could of course be that the programmers may be tempted not to work at their full capacity but the AFPL license would discourage that and let the subscribers monitor the progress. Another danger would be that a lot of these companies would pop up and nobody would work for free anymore but this is probably a stretch and wouldn't be necessarily bad.
Monkey sense
cnet predicted that linux would die and windows would continue to roll on because programers would not divert from money making to help competition come into play in the os world... but cnet is wrong the programers who make the games dont have to do $hit. there is always more then one way to do things ... cnet hasnt learned this yet!!
is it just me or did /. post this same thing a few months ago under the wine category with the title something like "Direct3d under wine"
mebbe i'm wrong
Some people get *ALL* the jokes... hah
- Toby
And this games stuff, well I played Diablo2 until the end. Under Linux. With wine. Took some fiddling to get it to run, but now it workls just fine.
This is exactly the problem with WINE... Sure, see the screenshots, almost everything works.
But! with some fiddling
Do you think Joe luser will be able to fiddle with WINE to get Diablo II running?
------
C'mon, flame me!
No sig for the moment.
So I'm guessing you weren't around when Motif and then CDE (and thus KDE) were conceived to take advantage of people's familiarity with Windows. Still, it is true that there is no reason not to borrow back and forth, but at some point there is a convergence.
"Beware of he who would deny you access to information, for in his heart, he dreams himself your master."
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
Emulate:
1. To strive to equal or excel, especially through imitation: an older pupil whose accomplishments and style I emulated.
2. To compete with successfully; approach or attain equality with. See Synonyms at rival.
3. Computer Science. To imitate the function of (another system), as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system.
WINE sure sounds like emulation to me.
Ranessin
Very strictly, yes.
Very correctly, yes.
Besides, as the title says, "Wine Is Not Emulation".
I believe that's "Wine Is Not an Emulator". In either case, it's wrong.
Ranessin
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?
Until then, hunt them bugs down and keep coding!
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
If companies spend less time re-creating wheels (porting games to different APIs), don't they have more time to improve game play?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~ the real world is much simpler ~~
--- -- - -
Give me LIBERTY, or give me a check.
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
DirectX 8 is a whole different ballgame. I'd be very impressed to see D3D8 implemented on Linux for a number of reasons: First, it has features so advanced that no current video card is D3D8 compliant. Second, it's a fairly safe bet that to achieve even reasonable performance, MS compiles vertex shaders into SSE, SSE2, 3DNow! or standard floating point code at runtime. Who do you think out there is willing and capable of spending the time required to write that kind of code?
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...
But will this really work? Emulators are not a new thing. Even the best emulators like "Bleem!" for PSX >> PC are still part of a niche market and are not nearly mainstream. What makes you think that this will be any different?
The two main roadblocks for emulators are the level of knowledge required to operate them, and the cost. Now I doubt that this Win32 Games on Linux software will be free. According to the Gamespy interview, they're using a subscription model. Roadblock number 1 is fully operational. (Of course people will priate the software if it's good.) Next, you have to remember that the users of this technology will be a subset of all Linux users. If you can install Linux, you can probably handle the technicalities of this software, so roadblock #1 is really not too large. In comparison with Bleem!, users of the very friendly PSX had to mess with PC 3D accelerator settings and and all kinds of stuff when they're used to slipping ther CD into the PSX box and having it work instantaneously.
But linux, among the general populace of Win32 game players is still a niche technology. Will niche software aimed at a niche of a niche group find a good body of subscribers? I genuinely hope that they can do it because it sounds like great technology, but I seriously doubt that they will get it to work. I am a Win32 gamer and would probably jump on the bandwagon, but I doubt my windows-using friends, even the ones who are technologically capable would migrate to linux to do what they already do on Windows.
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.
Wine and the Evolution team are working in parallel to port Microsoft's Virus Transport Protocol (VTP) to Evolution.
CVS access is open.
Having only read about beowulfs (and never actually installed one) and then about all the wine stuff (downloaded but not-installed-just-yet coz-I-got-other-stuff-to-doright-now) could some mad scientist out there write a 3d game encompassing a ridiculously large beowulf cluster ? Hell, I gotta Twin Celery linux machine just acting as my fileserver and proxy for 1% of it's cpu cycles (SETI for the rest). That would surely be worthy of a slashdot posting.
Two wrongs may not make a right, but three
who needs windows games when you have nethack? have YOU ever beaten it? nethack is the best game ever
Well - what about all those hot games out there like Red Alert 2?
It really eerks me when my roomate wants to reboot to play a game!
Sure linux comes with a lot of games - which are free, but nothing like the big budget games that those developers are making.
Get your Unix fortune now!
I'm really curious if they can get all of these games to run without getting into any legal trouble with Microsoft. I sure hope this isn't vaporware though.
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.
For many Linux users, a program that will let you use Windows games, you won't need Windows ever again. Only for the fact to play those games.
Simply put, playing Windows games on Linux is one of the greatest riddles of Linux. A great obstacle. But it will be overcome.
Wine..well, that's is a good program, but what if, (like me) you can't get it to open up, etc. Then you are in trouble.
Slashdot Hypocrisy at work?
Actually one of the screen shots they show in the article is of Red Alert 2 running on a KDE desktop. So yes it appears that it can run it.
Want this account? The password is geekizoid!
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.
I love Linux, I hate Windows. The problem with implementing WIN32 api to Linux is that, not only do you have to implement all the api calls correctly, we also have to implement all the bugs in the API exactly in the same way Redmond does it. Everybody knows that their is like a million bugs in the windows api and in DirectX. We'll never be able to find them all and by the time we do, all of a sudden, win32 will become win64 and DirectX will become "Microsoft Penguin Destroyer" we will have to implement another million bugs along with a billion mysterious api calls. As you can see, this is not feasible.
You stupid bastard, you don't have no arms left. It's just a flesh wound.
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.
The GNU's GPL does a good job of being worthless with good software under it.
So many people use it b/c it's almost the only choice besides BSD, and if its Linux, then why use the BSD license? You ask whats my answer or am I just bitching and complaining? I'm making my own and reading lots of licenses and really asking myself many moral questions and looking to see the implications of "what if all software followed this license, hypothetically of course, would that be a GOOD thing (aside from the monopolism)???"
Email me if you're actually interested or want to bash me or whatever... It's a four day weekend and these 486 boxes don't usually argue back.....
my Karma ran over my Dogma
This will also allow you to run MS Outlook...
They are trying to implement the virus execution layer from MS outlook, so here it comes!
Welcome to the world of the love bug, linux.
Brant
Brant
Argle. Bargle.
GNU DirectLinux API?
Nah, I've got a better name. It would run on the X Window System, allowing more or less direct access to video hardware.
How about X-Direct!
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.
In a perfect world, portability would really be just that, but, just in case anyone missed the news, it is not. However, building layers to translate this into that is not close enough to the core of things. The end result will always be analogous to Babelfish translations in quality.
Instead, would it not be better to get developers on all levels engaged in projects to move to more portable programming solutions, including Java, and to take the steps with those environments to make them serve up to the needs of the gaming industry?
I am no expert on the subject, but these are my thoughts. I would like to hear counterarguments and/or other thoughts on the subject.
I for one welcome our new SCOviet Russian overlords to whom all our base are belong.
Thats funny because no PS2 games are DVDs (as of right now...) if they were load times would be horrible as the drive reads CDs much much faster.
--
--
WHO ATE MY BREAKFAST PANTS?
i use adobe apps, and play games. My profession makes it so I MUST use adobe apps. Yes there are alternatives in the Linux world, but I don't care what anyone says, Gimp is no photoshop! Nevermind, image ready, illustrator, etc.. BUT! I would probably make due if gaming was possible. The biggest question for the success of this project in my mind is how big of a performance hit would you be taking? The hardcore gamer does everything in his/her power to eek out that last FPS. This would not help that cause. But the concept of actually having a viable choice and alternative to M$windoze is very appealing. Even at such a high cost. One thing is certain.. This is one of the many steps necessary to get the masses to switch. I have been ready to dump windoze for YEARS. But I have needs. Deal with them and I will drop windoze like a bad habit.
sig.object.lame
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.
Well, this is fine and dandy, but I won't use it. I'm with most of the people here who disagree that an application layer will bring any good to the Linux platform (if not hurt it). I prefer native binaries to run instead of having to put them through an emulator/application layer. It's just my preference and two cents worth.
Aiken Matienzo of the Avalon Project
As simple as that, what WINE does, in the long run, hurts Linux. But damn, I just cant wait to put my hands on the next version. /. could start a poll here... Did you ever bought a "Linux game"? (like one of those from loki games). My bet is that we're about to have a 90% NO on that.
Now what Linux really needs is something that shows big companies that "Hey, we are here, we use linux and we will give you loads of money for your games IF i can run then on MY operating system!"
Now i think
We have to start the circle of demand/offer here, once we get the ball rolling, no problem. Just my humble thoughts on the subject.
Rio de Janeiro's dwellers are stupid. No, really.