Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Linux Software

Windows Games On Linux 202

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."
This discussion has been archived. No new comments can be posted.

Windows Games On Linux

Comments Filter:
  • by Anonymous Coward
    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...)
  • by Anonymous Coward
    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.
  • by Anonymous Coward
    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.
  • by Anonymous Coward
    Slashdot used the wrong icon for this should have been "Bill Borg". Games run this way will never fully exploit the system as native games could...leaving Windows as the 'best' platform to run Windows games.

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

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

  • by alewando ( 854 ) on Saturday March 24, 2001 @12:47PM (#342365)
    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.

  • Red Alert 2 is specifically emulator hostile.

    Will it even run under VPC?
  • 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.
  • "Open Source" is VERY relevant to the average end user. It means that they have a platform that won't just suddenly go away because some company committe somewhere decided to mothball it. "Open Source" infact gives an AltOS the same sort of edge that Microsoft has.

    Free Software can remain and thrive in circumstances that would KILL (and has KILLED) similar alternatives that were payware.

    "Will it be around tomorrow?" is VERY relevant to the average end user.
  • IE5 is not significantly better. Even shill mags admit this.

    Mailers may be a dime a dozen on Windows, but that alone won't compell people to continue using Monopolyware.

    Office apps might be a stronghold. However, people still care about their pocketbooks. So do corporations. Sun may be able to "cut of Microsofts air supply".

    If they ever do, a mob of penguins will be right there ready to take advantage of the situation.

    Even Lemmings are getting tired of paying over and over again for the same old crap. The common consumer might not be discerning, but the common consumer is CHEAP.

    Any attempt by Microsoft to "enhance revenue" won't help things.
  • 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.

  • True, which is why I'm hoping this won't be Linux-centric--I run a freer OS than "GNU/Linux".
  • Ayep-and here's another [].

    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 k5 crowd sure posted a lot of crap about WINE.

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

  • You sure picked a helluva way to do it, too...a license that requires all software linking to GPL code (with a very liberal definition of "linking") be compatible with whatever the hell the GNU steering commitee decides is compatible.

    Forgive me if I fail to share your optimism.

  • 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. :)
  • by dattaway ( 3088 ) on Saturday March 24, 2001 @02:43PM (#342378) Homepage Journal
    Don't dismiss a particular choice of operating system, because of "it had a lot of hype." OS2 did indeed have a vocal base of users and had marketing behind its sales; however, it wasn't hype. OS2 worked. Let me rephrase that: It was reliable. Although the OS2 releases of yesterday are outdated by our standards, businesses still use it. Where I work, it is a good platform for controlling large, complex machines where failure is extremely expensive.

    How reliable is it? The OS2 control computers at work have not needed to be rebooted over 5 years since its installation. Not bad.
  • In case you didn't know, tribes is available for linux,too. Check

    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.
  • 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!
  • Exactly. Windows 3.1 wouldn't have gotten anywhere if it didn't support DOS apps. Windows 95 wouldn't have taken hold if it didn't run Windows 3.1 apps. Backwards compatibility is essential. But then you have to offer something over and above backwards compatibility -- some sort of value add that makes it worth moving up.
  • Welcome to the world of file permissions, love bug.
  • 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.
  • by m2 ( 5408 ) <> on Saturday March 24, 2001 @04:07PM (#342390) Homepage Journal
    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.

    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.

  • All those bullet points have one thing in common: the average user doesn't give a damn about them.
  • 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.

  • Nice examples. But, unfortunately, none of them are anything that a user who "buys a PC for games and simple office work" cares a whit about.

    So, really, they don't do anything to answer my question in a way that is postive for Linux.

    Again, I'll ask, what non-commercial Linux software is there for the user who "buys a PC for games and simple office work" that is better than what is available for Windows? What overwhelming compeling reason is there for an average user to switch to linux as their main home OS?

  • by Quarters ( 18322 ) on Saturday March 24, 2001 @03:52PM (#342400)
    What non-commerical linux community written software that a consumer who buys a pc for games and simple office work is better than what can be had for Windows?

    Netscape 6? No. Sorry, IE5 is a better browser. Mail clients? No. They're a dime a dozen on Windows also--and many of those are excellent mail clients. THe same holds true for news readers, ftp clients, and IRC programs.

    Office apps? Maybe But people will want to use at home what they use at work. Games? I don't think there are many non-commercial Linux games that hold a candle to any commerical offering (on either Linux or Windows). In the commerical games camp you only have ports of games that already exist on Windows.

    So what, if anything, would a Windows user see in non-commercial linux software that would make them want to switch OSes?

  • And you use Linux? LOL.

    FreeBSD actually -- I paid for my futzing only once :)

  • by hugg ( 22953 ) on Saturday March 24, 2001 @01:00PM (#342404)

    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?
  • What overwhelming compeling reason is there for an average user to switch to linux as their main home OS?
    I think many average users would prefer an OS that didn't require a complete re-installation every so often.

    Tom Swiss | the infamous tms |

  • Remember that OS's are not important. Apps are.


    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:

    • System A takes a day to learn the basics of use. There is a 20% chance on any given day that it will crash and need to be rebooted. There is a 10% chanage that in a year's time it will need to be reinstalled from scratch, destroying all your data. It has friendly dancing paperclips! There are lots of "...for Dummies" books about it.
    • System B takes a week to learn the basics of use. There is a 1% chance per day of needing a reboot and a 1% chance per year of needing a reinstallation. (And if a reinstallation is needed, you've got a good chance of being able to salvage your data). No dancing paperclips. It is not for dummies.

    I think a large number of "average users" would pick system B.

    Tom Swiss | the infamous tms |

  • Except that Win32 is entirely irrelevent for this discussion. We're talking DirectX, and that changes significantly every year.
  • Win32 isn't entirely irrelevant in this discussion. Firstly, DirectX objects are just a subset of the set of all possible COM objects. If you're going to reproduce DirectX on a system, you'll have to reproduce OLE (at least to some degree.) Secondly, several games programmers use the ->GetDC() member of the IDirectDrawSurface interface at some spot in their games. When the surface is locked and a device context handle is returned, the program is obviously going to use it in classic GDI calls.
    I don't know how terribly common the GDI is in *real* games. The GDI is awefully slow, and most games use their own text rendering functions anyway. As far as I can see, the only game that might have some problems with a lack of the GDI might be Unreal, which (I think) uses the GDI to display options dialogues. Besides, this whole thing is running with Wine, so the GDI issue is moot.

    Right, and in fact this newest release makes the whole DirectDraw discussion pretty much dead. In any case, the way that COM objects are meant to be designed is that updated interfaces must be queried. Right now, a game might attempt to create the first version of the DirectDraw object: CoCreateInstance(CLSID_DirectDraw, NULL, CLSCTX_INPROC_SERVER, IID_IDirectDraw, (void**)*pdd) and if it fails then the game can abort with a message that the required version of DirectX isn't installed. So long as OLE/COM is supported properly, there won't be any problem with the changes made to DirectX from year to year that Windows machines without the latest libraries won't have too.
    I know how DirectX works, its my favorite API to work with. However, my point was that DirectX changes very significantly (particularly between 6.0, 7.0 and 8.0) and it might be too hard for a company to keep up with the changing interfaces. Even if older code works well, it is usually only a matter of a weeks before new games using the latest interfaces come out. They might not be able to keep up with the changing interface.
  • 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.
  • DirectX is probably the single best thing about Windows, and it's actually one damned good game developement API.
    Amen to that my DX brotha'!

    Actually, I kinda wish somebody would implement something like DirectX for Linux. Its a shame such good technology is tied to Windows.
  • First, there is a lot more the DirectX than just D3D. DirectInput is the most complete input API on the planet, DirectSound is a very good sound API, and DirectMusic blows everything else out of the water (except maybe Be's media kit, but that isn't meant for games :( DirectPlay is great because it is protocol independant, and DirectShow/etc is great because it takes full advantage of video hardware.

    Second, D3D *is* more complicated than OpenGL, but that's because its so much more powerful. It allows to to manage the nitty-gritty aspects of the graphics pipeline that OpenGL abstracts away. For example, OpenGL doesn't even give you control over the uploading of texture or allocation of vertex buffers without using (sometimes unavailable) extensions. Also, D3D these days is much more feature filled and power than OpenGL (unless you count prorietory extension's like NVIDIA's or ATI's, which, FYI are not compatible with each other). Lastly, D3D 8.0 seems to be a hair faster than OpenGL (again, the cost of abstraction) a well.
  • Yes it does, if you knew anything about DirectX. Because there were so many layers of abstraction under Win32, game makers used DOS. However, they had to create dozens of hardware-specific drivers since DOS doesn't support advanced functionality. DirectX allowed vendors to get the performance of DOS, and the hardware abstraction of Windows. FYI, DirectX had the following design goals:

    A) Be thin and fast: Meet or exceed the performance of DOS.
    B) Be flexible: Take advantage of hardware acceleration whenever possible, emulate when not. Support hardware features quickly, and provide new emulated features that provide a carrot for hardware manufacturers to implement these new features in next-gen hardware.
    C) Be humble: Stay out of the developer's way, don't impose any artifical constraints on game design.
  • 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.
  • 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.
  • 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.
  • 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?
  • ...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 [www.starflight3] 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.)"
  • 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.)"
  • 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.)"
  • by Jace of Fuse! ( 72042 ) on Saturday March 24, 2001 @02:19PM (#342428) Homepage
    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 -- In case you haven't noticed, that apraisal of DirectX hasn't applied since DirectX 5, maybe even as far back as DirectX 3.

    Most recently, games for DirectX really make one wonder why everything else about Windows is so bad.

    DirectX is probably the single best thing about Windows, and it's actually one damned good game developement API.

    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?

    Yes. And I can't remember the last time I had something that wouldn't run on my fairly typical system (GeForce 2 GTS, Sound Blaster Live, Pentium III 800).

    I realize some people have "Less than Optimal" systems for gaming, and some hardware has some pretty bad support for DirectX, but any decent hardware is going to have good DirectX support, and if someone says they constantly have trouble in DirectX games I'd have to question their hardware purchasing decisions more-so than the quality of the API or the games they are buying.

    Having a DirectX implimentation for Linux could generally be a GOOD THING. There are many people who only keep Windows around for games.

    I'm wondering if Microsoft will try to put a stop to this before it gets too far. But they've yet to (as far as I know) take action against Wine, so maybe they know fighting the beast head on will only make it stronger.

    Here's to hope.

    "Everything you know is wrong. (And stupid.)"
  • You'll have to purchase this emulator. What's the difference (and by the way, I was advocating piracy)
  • Yes. And I can't remember the last time I had something that wouldn't run on my fairly typical system (GeForce 2 GTS, Sound Blaster Live, Pentium III 800).

    Yeah, because that seems to be the 'stock' test system nowdays. I had hideous problems getting my on-board sound chip working properly, and I finally gave up and bought an SB Live. EVERYTHING seems to support GeForce/SBLive (including xfree86/gnome). Move from that combo at your peril.

  • DirectX is probably the single best thing about Windows, and it's actually one damned good game developement API.

    Funny, John Carmack's logic behind *not* developing QuakeII and up in Direct3D has always been that OpenGL was much easier, and much saner than anything Microsoft could deliver at the time. Maybe things have changed, I dunno. But I can say that the D3D games that I've played generally run okay.
  • by Eil ( 82413 ) on Saturday March 24, 2001 @04:55PM (#342436) Homepage Journal

    You have a valid point. However, as a /.er, you seem to have taken things to an incredible extreme.

    There are three other points that I'd like to bring up that support my belief that running Windows apps in a Linux environment is overall a good thing.

    1) From the users' point of view, the benefit of backward-compatibility (yes, windows is backward. :P) gives them more options in the long run. How many times have we all heard a random Linux newbie claim that he tried it, liked it, but couldn't do without some critical piece of software that was tied to the Windows platform? All too often, it is often this minor detail that holds people back from becoming Linux converts. This is the entire motivation behind WINE.

    2) From the developer's point of view, this means that they can herald their Windows software as being able to run perfectly fine in Windows as well as Linux. This provides a really good stepping stone for Windows software houses to easily switch over to Linux if they decide they're ready.

    One particular thing that makes it even easier is the development of winelib. winelib lets developers simply recompile their existing Win32 code (perhaps with a few minor modifications) so that it can run *natively* on Linux. If ever they decide to toss out Win32 support completely, it would take some major rewriting of the program, but with winelib, this step isn't really neccessary. By the time they get around to their next major software product, it might be programmed to run in *NIX environments from the ground up.

    3) What do you think would be the result if the core of the Linux community decided to lock themselves into only running native applications as you suggest? I think at least one of the results would be that the Linux community as a whole would eventually have the stereotype of being a closed group of zealous stalwarts. (Think of the current Mac user stereotype, or those who still use OS/2, or who haven't yet replaced their Amigas.) I mean, we have those already (as your post proves) but the thing that makes Linux, nay, the entire Unix philosophy so powerful is its flexibility. Once in awhile, curious people ask me what Linux can do [as opposed to Windows] and I always answer them, telling them nothing less than what I firmly believe: "Anything you want it to."

    Without that flexibility, Linux would simply be replaced by something else and be written into the history books as some Fin's college project that happened to have a small cult following.

    So you see, non-native application support is not about always trying to keep up with Microsoft so that we can run the latest Windows apps too, it's much more for the benefit of the software developers and users; to provide them with a very realistic stepping stone while they make the transition from Windows to Linux, should they want to do so.

    By the way, I'm curious whether or not you have an opinion on the Linux binary compatability feature in FreeBSD.
  • Here's a few:
    • Apache: Beats IIS in security and portability
    • PHP: Runs neck and neck with ASP or beats it
    • gcc: More standards compliant than VCC
    • bash: Better than the Win2k shell by far
    • perl/python: Find me a better commercial scripting language, please...
    • The linux kernel itself: More stable than Win2k and far far far superior to Win 98/95
    Granted, these aren't for the consumer doing basic office work or games (except for the kernel), but they're much more mature apps than the office/game apps that haven't been around as long. These point to what's coming, as do wonderful apps like Gnumeric and Konquerer, which are both almost set to give their windows counterparts a real run for their money. Give the community some time, it's all a work in progress.

    "I may not have morals, but I have standards."
  • 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."
  • 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.

  • by JohnG ( 93975 ) on Saturday March 24, 2001 @01:10PM (#342444)
    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...
  • by emmons ( 94632 ) on Saturday March 24, 2001 @12:54PM (#342447) Homepage
    Native support is nice and all, but if nobody develops for it, it's rather pointless. At least this way Linux can GROW to the point that if an API is developed which runs faster on Linux than DirectX, developers will write games for it.

    OS/2 started with a rather large following but then lost it. Linux is starting with (relatively) no following. There's nothing to lose.

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

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

  • Look what happened to IBM's OS/2 platform.

    Well, let's see... important, valuable applications came out for Win32 only, and OS/2 couldn't run them. Thus the advantages of OS/2 were not interesting to any user who wanted to run, say, Photoshop.

    In other words, people had to choose between running OS/2 and running certain applications. This made it harder for them to choose OS/2.

    It is clear to me that the more backwards-compatible free OSes can become, the easier it becomes for a person to choose a free OS instead of Windows.

    And, consider this. Right now, game companies write only for Windows, and test only on Windows. If WINE and WineX get good, and really large numbers of gamers start running games under WineX, the game companies might start testing under WineX. Wouldn't it be cool to have the games work under WineX out of the box, instead of having to hack WineX to make them work? You might even see game companies making contributions to WineX.

    If you want game companies to write native games for free OSes, first you need a really large number of desktops running the free OSes. One way to grow the number of desktops is really good backward compatibility.

    This is good news, I am certain.


  • 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?
    Talk to the speed geeks at SGI [].
  • 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
  • by Dark Paladin ( 116525 ) <> on Saturday March 24, 2001 @12:45PM (#342460) Homepage

    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

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

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

  • 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 [].

  • by yerricde ( 125198 ) on Saturday March 24, 2001 @06:56PM (#342469) Homepage Journal

    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

    • Run Linux on Windows 2000. This works through VMWare ($300; introductory offer has expired) or through Cygwin and has stability problems because the virtualizer is running on a kernel whose kernel-mode video drivers are one bit short of a proverbial byte. And there's still the virtualization overhead.
    • Run Windows 2000 on Linux. Again, VMWare costs $300. It also doesn't support DirectX, which is used by several multimedia apps.
    • Run Wine on Linux. Wine is a subsystem for x86-based Linux and BSD systems with an X server that implements the ECMA Win32 standard []. There are about as many incompatibilities between Wine and Win32 apps as there are between ntoskrnl and VMWare. It's also a bit faster than VMWare because the apps are merely running on a different subsystem instead of a partial emulator.
    • Run Linux on my server and Windows 2000 on another box, which costs $1000 but adds the advantage of being able to run Direct3D apps.
  • 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.

  • Let me ask you a question. If a second-tier PC manufacturer like Time here in the UK offered a PC with full Windows compatibility for $100 less do you think it would sell?
  • Certain game companies didn't put it on the shop shelves, at least in the UK anyway, therefore ignoring their primary method of shifting units. I know this is also down to the shops, but I see Mandrake, SuSE and RedHat boxes there, so it isn't impossible.
  • by cyber-vandal ( 148830 ) on Saturday March 24, 2001 @10:37PM (#342487) Homepage
    Konqueror 2.1 is a better browser than both of them. Office 97 runs under Wine AFAIK and so the last hurdle is the games, which is now being worked on. My dad is a typical Windows user, uses it for browsing, Office work and games. But he hates Windows. Give him a way to continue doing this without having to put up with constant crashing and he'd switch in a minute. He's got Windows 2000, but it suffers from the same problems as Linux, incomplete hardware support and fewer apps and unlike Linux it still crashes randomly.
  • "
    What overwhelming compeling reason is there for an average user to switch to linux as their main home OS?

    For someone who's about to throw away a 486/pentium class PC and replace it,

    $500 for the cost of windows + office

    the ability to use their old computer as a network terminal and effectively have two new computers

    crash proof

    free tech support from their friends who no longer use windows because it's too crap

  • "
    Gone forever are the days of having to continuously remember (and tell each game) that your SBPro was installed on IRQ 7, I/O address 220, DMA 1.

    I have two soundcards in my machine [SB 16 - default, SB Live - not default]

    I am fed up of having to switch the connectors in the back of the machine to make the sound come out of the right set of speakers.

    Why do DX games ignore the default and go for the more expensive card instead? My DOS games can get it right.
  • by AnswerGuy ( 164990 ) on Saturday March 24, 2001 @12:55PM (#342493)
    There are millions of apps written for Win32. Microsoft's market exists primarily because of backwards compatibility. MS is never going to do anything that would make their really big customers angry either. There are a lot of custom apps that big companies have written that work fine for them and don't need to be updated. When the Win64 api comes out there will be extremely few people using it, and it will support Win32. Thus anything that will be released in the next few years for the mass market will use Win32.

    Look at games until about 5 years ago they still were mostly written for DOS. It will take years before the game companies switch to anything which isn't compatible with Windows 98 and we can be compatible with it rather easily.
  • I realize some people have "Less than Optimal" systems for gaming, and some hardware has some pretty bad support for DirectX, but any decent hardware is going to have good DirectX support

    Just to add the this point, it wasn't that long ago that you had to worry about every single game/program supporting your hardware. As much as I dislike some of the things Microsoft has done, I really can't argue with how much easier game configuration has gotten. Gone forever are the days of having to continuously remember (and tell each game) that your SBPro was installed on IRQ 7, I/O address 220, DMA 1.

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

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

  • 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!
  • You're missing an important point, though: Linux is free. The choice isn't between buying Microsoft's OS and buying IBM's OS, it's between buying an OS and not buying an OS. The only reason I have Windows on my hard drive is to play games; if there were a reliable way to do without it, I'd never buy (or pirate ;) Windows again. OS/2 had to be substantially better to get people to buy it instead, whereas Linux just has to be interesting enough to spend a couple hours getting it installed and getting used to it.

  • Games are the major and virtually only reason I have right now not to abandon M$ (that and the fact that I have to use Word once in a while). An implementation of DirectX that works seamlessly with Linux may seem to be an impossible dream (IANAC (I Am Not A Coder), but just from the surface it seems that they can't get it done without running into proprietary code somewhere), but if someone can pull it off...oh, man, I'd love it.

    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.

  • Why are so many people ready to sink a piece of software just because it's not GPL'd? I'd rather have decent closed software that I paid for than a bunch of 'free' crap. That isn't to say free=crap, but I notice a significant absence of quality apps in certain areas for Linux - that's why I'm still spending more time in 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.

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

  • 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.
  • 1) Wine Is Not an Emulator. It is a binary loader and API translator. Windows .EXE files are loaded and executed directly by Wine, without any form of CPU instruction translation involved.

    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

  • by Edgewize ( 262271 ) on Saturday March 24, 2001 @01:17PM (#342527)
    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...
  • isn't there a better way to go thatn WINE?
    There is a company called VMware [], which has made a virtual machine that allows Windows to run under Linux. It is a commercial application, but it is one of the most reliable programs out there.
  • 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.
  • Somehow you think fighting fair is going to help you win. Why would most people want to come to linux? Not because SAMBA is faster than Windows File and Print sharing. Christ.. They don't care about how awesome apache is or how much better lotus domino server runs on linux than AIX or whatever.. The consumer buys a pc for games and simple office work. I see this as an excellent opportunity to bait a bunch of people over here, get them poking around with non-commercial linux community written software and driving home the fact that linux free apps are generally better than the ones companies charge so much for. I fail to see how getting one more person educated on this platform is a *bad thing*. OS/2 didn't fail because it had winos2 compatibility, it may have multitasked better, it may have handled alot of things better but no one (cept os2 zealots) thought it was more enjoyable to use than windows 95. I mean really.. go back and look at os2 again and compare it to 95. What's the point? Linux has potential and the only thing we need to do is get more people installing and monkeying around with it.
  • 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.
  • 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...
  • by UltraBot2K1 ( 320256 ) on Saturday March 24, 2001 @12:41PM (#342552) Homepage Journal
    Why would anyone want to play Windows games. I can already play thousands of variations of Solitaire and Minesweeper on Linux.

    That pinball game that comes with Win2K is kind of cool, though.

  • by Canonymous Howard ( 325660 ) on Saturday March 24, 2001 @02:06PM (#342556)
    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.

Our business in life is not to succeed but to continue to fail in high spirits. -- Robert Louis Stevenson