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

 


Forgot your password?
Close
typodupeerror
×
Windows Wine Linux Games

Steam Gets Built-in Tools To Let You Run Windows Games on Linux -- Now Available in Beta (pcgamesn.com) 206

Posted by msmash from the bridging-the-gap dept.
Steam Play -- Valve's name for its cross-platform initiative -- is getting a major update, adding built-in tools that would allow users to run Windows games on Linux. It's now available in beta. From a report: The new tools run on Proton, which is custom distribution of the widely-used Wine compatibility tool. In the most practical terms, this means you can now download and install Windows games directly from the Steam client without any further fuss. Valve is currently checking "the entire Steam catalog" and whitelisting games that run without issue, but you can turn off those guidelines and install whatever you want, too.

Proton should provide enhanced performance over Wine in many cases, according to Valve. DirectX 11 and 12 implementations are now based on Vulkan, and performance in multi-threaded games "has been greatly improved compared to vanilla Wine." You'll also see better fullscreen and controller support with Proton. It's also fully open source.
This discussion has been archived. No new comments can be posted.

Steam Gets Built-in Tools To Let You Run Windows Games on Linux -- Now Available in Beta More

Steam Gets Built-in Tools To Let You Run Windows Games on Linux -- Now Available in Beta

Comments Filter:

  • Works (Score:5, Informative)

    by TAiNiUM ( 66843 ) on Tuesday August 21, 2018 @08:37PM (#57170900)

    Working well for me so far. Windows games are installing and running. Some people are just adding the path to their Windows Steam games in the Linux Steam client and find that Steam Play is running those games!

    Hopefully this doesn't give companies an excuse to ignore native Linux development.

    • Re:Works (Score:5, Insightful)

      by tepples ( 727027 ) <tepples.gmail@com> on Tuesday August 21, 2018 @08:40PM (#57170910) Homepage Journal

      Hopefully this doesn't give companies an excuse to ignore native Linux development.

      How is a Wine app on a GTK+ system any less "native" than a Qt app on a GTK+ system? It's literally just a different set of userspace libraries.

      • Re:Works (Score:5, Informative)

        by Anonymous Coward on Tuesday August 21, 2018 @08:53PM (#57170946)

        How is a Wine app on a GTK+ system any less "native" than a Qt app on a GTK+ system? It's literally just a different set of userspace libraries.

        Wine is a layer in the middle that adds some inefficiency, compatibility issues and bugs of its own. Albeit not much - the Wine devs are pretty awesome to do what they do - but it's there.

        The biggest issue with companies ignoring "native" Linux is they'll tend to stick with the tools for the platforms they target and they will tend towards the most modern APIs particularly for graphics where modern generally means faster and with more features.

        Wine is always playing catch-up with those APIs so there's a very good chance today's Windows game will be years before it's even half playable on Linux using Wine.

        • If the dev tests on Wine (Score:5, Interesting)

          by tepples ( 727027 ) <tepples.gmail@com> on Tuesday August 21, 2018 @09:59PM (#57171168) Homepage Journal

          Wine is a layer in the middle that adds some inefficiency, compatibility issues and bugs of its own.

          How much more so than GTK+ as "a layer in the middle" between an application and Xlib?

          The biggest issue with companies ignoring "native" Linux is they'll tend to stick with the tools for the platforms they target and they will tend towards the most modern APIs particularly for graphics where modern generally means faster and with more features.

          How much of this issue goes away if a developer instructs quality control to treat Wine as a fully supported platform alongside Windows 7 and Windows 10? That's how BGB (Game Boy debugger), FCEUX (NES debugger), OpenMPT (sample based sequencer), and FamiTracker (chiptune sequencer) work: the developer ships Win32 binaries tested on both Windows and Wine.

          • How much of this issue goes away if a developer instructs quality control to treat Wine as a fully supported platform alongside Windows 7 and Windows 10?

            All of it, practically speaking. Wouldn't that be nice?

            • Re: (Score:2)

              by rtb61 ( 674572 )

              It depends upon how well any particular Linux distribution is aligned with Wine and the various hardware drives to produce a solid reliable outcome, probably with a drop in performance, to ensure no game crashes the system but can crash wine. So you never need to reboot the system, only reboot wine, its for gaming afterall and so you want other things to run liably as well. This tied to a more modern era of in home servers, keeping the corporations out and you family privacy in ie your own in home encrypted

          • Re: (Score:2)

            by adolf ( 21054 )

            That doesn't feel right (I want muh NATIVE ELF BINARIES!), but it makes perfect sense: If Wine is a supported platform then there's nothing really to worry about.

          • Re: If the dev tests on Wine (Score:2, Interesting)

            by Anonymous Coward

            How can you be so stupid.GTK and QT and Motif are widget sets. Precanned libraries containing styling for drop-down lists and buttons and so on, drawn as bitmap on your screen. On windows you get only 2 - aero and GDI and with Windows 10 only one style again... wine is a completely different beast

          • High level (Score:5, Informative)

            by DrYak ( 748999 ) on Wednesday August 22, 2018 @06:16AM (#57172618) Homepage

            Wine is a layer in the middle that adds some inefficiency, compatibility issues and bugs of its own.

            How much more so than GTK+ as "a layer in the middle" between an application and Xlib?

            Much more, for the reason that GTK+ is a layer that provides high-level functionnality (I want a button, I want a window, I want a drop list, etc.) to the application, while itself talking to a low level interface (mostly used for blitting and rectangles filling).

            What wine is doing is taking a certain low-level API and reconverting everything into a completely different low-level API.

            It would be like if you took that Xlib API, but instead talking to the Xlib library it self, you talk to a separate layer that takes in Xlib API and translates it into something that is displayed using openGL, running on SDL, so that it could be used on some weird gaming console, because that GTK+ application is compiled with a GTK version hard-coded in that isn't supporting OpenGL.

            Could be entirely solved by having that application built with GTK supporting OpenGL as a render back-end, but it cannot be done, because you have zero control on it, thus you need a rube goldberg layer of pancackes of middle layers to get the application working.

            Wine is that adaptation layer.

            That's why it would be great if eventually one day developers started to target Linux too.

            But until then, there's the chicken-and-egg problem of linux not being a popular gaming platform, thus not worth spending resources on from the developers point of view, and in turn never getting popular because there are no games on it.

            Thus...

            How much of this issue goes away if a developer instructs quality control to treat Wine as a fully supported platform alongside Windows 7 and Windows 10? That's how BGB (Game Boy debugger), FCEUX (NES debugger), OpenMPT (sample based sequencer), and FamiTracker (chiptune sequencer) work: the developer ships Win32 binaries tested on both Windows and Wine.

            Yup, developers at least starting to give attention to wine is a good intermediate step.
            That at least solves the "users won't pick up linux as a platform due to lack of games" part of the equation.

            And who knows, maybe this will suddenly make steam-on-linux a popular platform (maybe because it could enable cheap linux "steambox" gaming consoles ?)

            And once these "steambox" gaming console become popular enough to show on the radar of the devs, some will try putting effort into true native linux builds, eventually ?

            • It would be like if you took that Xlib API, but instead talking to the Xlib library it self, you talk to a separate layer that takes in Xlib API and translates it into something that is displayed using openGL, running on SDL

              Or shorter: "an X server that uses SDL for output," like the "XServer XSDL" app for Android [google.com]. That and the "GNURoot Debian" app are necessary in order to get existing applications running on some popular Linux-based distributions, as they come with Linux proper (a kernel) but not GNU or X.

            • Re: (Score:2)

              by AvitarX ( 172628 )

              How much does windows really cost on a computer?

      • How is a Wine app on a GTK+ system any less "native" than a Qt app on a GTK+ system? It's literally just a different set of userspace libraries.

        Not quite, though.
        Most of those userspace libraries are emulating behavior that isn't well defined and translating behavior with a *very* thick compatibility layer encompassing *literally* every single aspect of a program's interaction capabilities.
        Wine isn't implemented as a personality within the kernel to interact directly with native primitives, nor is X running a GDI subsystem.

        Ultimately, I guess what is native then?
        I suppose it's shades of gray. One could argue, I suppose, that qemu binary cross-

        • Re: (Score:2)

          by tepples ( 727027 )

          Ultimately, I guess what is native then?

          I personally would draw one line between Wine ("Wine is not an emulator") and a same-architecture VMM such as VirtualBox and another line between a same-architecture VMM and an actual emulator.

          • I personally would draw one line between Wine ("Wine is not an emulator") and a same-architecture VMM such as VirtualBox

            Why, though?
            If we're going to be arbitrarily arbitrary, we can say that KVM is just another set of userspace libraries, with a thick translation layer between the application and the host kernel.

            and another line between a same-architecture VMM and an actual emulator.

            Why, though?
            qemu is capable of fully emulating an x86 binary and interfacing it directly with the host OS. It's basically just an ELF loader, and a translation layer.

            I'm not arguing that you're wrong, by any means, just that I think it's a bit disingenuous to say that a toolkit library such as GTK or Qt are equi

            • Re: (Score:2)

              by tepples ( 727027 )

              You're correct that paravirtualization [wikipedia.org], which modifies the kernel to accept a simplified machine model presented by the VMM, blurs these lines. But historically, publishers of proprietary operating systems have been hostile toward production use thereof as a guest under paravirtualization.

              The other big differences:

              1. Wine is $119.99 cheaper than Windows in a VM. It'd be technically possible to automatically provision a VM on the user's machine on demand, but I doubt that Valve would want the legal hassle as

              • The other big differences:

                Oh I really don't disagree with the use of Wine at all. I think it's fantastic that some Big Money is picking it up to help those guys out. Their job is horridly complex (emulating a more or less undocumented API, with a black box implementation) and it's a miracle it works at all. I've used Wine for many years.

                Being this is happening with Steam, which is a large enough distribution platform that developers actually pay it attention- we may see Windows apps even targeted for Wine compatibility... which is

      • Clothes vs a giraffe costume (Score:5, Insightful)

        by raymorris ( 2726007 ) on Wednesday August 22, 2018 @12:09AM (#57171600) Journal

        Your clothes are a layer between your skin and people observing you.
        A giraffe costume is a layer between your skin and people observing you.

        Your clothes are made to fit you. They don't hide your shape or size, or make you look like something other than what you are. They are a natural fit to a human of your size and shape. They don't get in the way of using your hands and mouth, the interfaces you are designed to work with.

        An giraffe costume isn't a natural fit for you, and it hides your actual size and shape. it gets in the way of using your hands and mouth naturally. It's awkward, and definitely not what you want to wear while running a race, because it slows you down.

        Wine is a Windows costume for Linux, to make Linux look kinda like Windows. Rather than exposing the Linux interfaces in an organized, easy to use way as GTK does, it hides the Linux interfaces the same way a giraffe costume hides your mouth, and the result is muffled communication. GTK is designed for Linux, to fit properly on Linux, the same way your clothes are designed to fit properly on your body.

        • Your clothes are made to fit you.

          That depends to an extent on whether you saw a tailor or bought off the rack.

          They don't hide your shape or size

          With exceptions. For the past several decades, a lot of money in the fashion industry has gone toward hiding the overweight brought on by the modern American diet. The loose clothing commonly associated with the Middle East hides the shape of the body for two reasons: as a side effect of "chimney effect" convective cooling design for hot weather [theguardian.com] and (allegedly) to distract the brain from sexual desire. The loose ankle-length vestme

      • How is a Wine app on a GTK+ system any less "native" than a Qt app on a GTK+ system?

        Got to correct you there, you're a bit unclear on how these stack. Qt apps never link to GTK+ libraries. Both Qt and GTK+ sit on top of a window manager, to which they link, in addition to many other low level libraries such as Xlib.

        • Qt apps never link to GTK+ libraries. Both Qt and GTK+ sit on top of a window manager, to which they link, in addition to many other low level libraries such as Xlib.

          Likewise, Wine sits on top of a window manager, to which it links, in addition to many other low level libraries such as Xlib. In my mind, this makes Wine a widget set, little different from Qt or GNUstep.

        • Got to correct you there, you're a bit unclear on how these stack. Qt apps never link to GTK+ libraries. Both Qt and GTK+ sit on top of a window manager, to which they link, in addition to many other low level libraries such as Xlib.

          Ah, but what of QGtkStyle [wikipedia.org], a part of Qt since Qt 4.5? It uses GTK+ to draw GUI elements for Qt applications, thereby making them look [somewhat] like GTK+ applications (save for the excessive whitespace that seems to appear in all Qt apps.) There is a corresponding equivalent for going the other direction as well, but I can't recall its name at the moment and it's not directly relevant to the conversation anyhow...

      • because a Linux binary is native to the Operating system, which is at a lower level than being native to the desktop environment. QT and GTK apps on a Linux system are both Linux native applications, Wine apps, are not.

        • Different people have different opinions on the philosophical question of what an operating system comprises. As long as defining "operating system" is hard, defining "native" will also be hard. These questions should help determine where one might draw the line:

          Is an executable loader part of "the operating system"? In Linux, executable loaders are not part of the kernel except in the special case of a statically linked ELF. Everything else, such as Wine's PE format or an ELF that uses a shared library, go

    • if the games work? I suppose you might give up a few FPS here and there, but it's 2018 so I just don't feel the need to count every frame like I did in the 90s when I was pushing the limits at 20 fps.

    • Hopefully this doesn't give companies an excuse to ignore native Linux development.

      The opposite actually. It gives game developers confidence that the Linux game market is real and here to stay. And that it is likely to undergo rapid expansion. Obviously, we prefer native ports.

    • Comment removed based on user account deletion

    • It's a great excuse actually. When you create a Windows game, you create it for at most three platforms (Windows 7, 8 and 10.1 which largely have the same behavior, same APIs, same ABIs, same libraries; sans Direct3D 12 which is exclusive to Windows 10).

      When you create a game for Linux you have to target a billion of platforms [altervista.org]. Let game devs target Windows and test if the game properly runs under Wine/Proton - that would be enough.

  • This might be the dealbreaker for me (Score:2, Interesting)

    by Anonymous Coward

    Iâ(TM)ve been flirting with Linux for years, but using windows only because most games donâ(TM)t run on it. If this works and works well, iâ(TM)ll probably switch

    • Re:This might be the dealbreaker for me (Score:5, Funny)

      by Anonymous Coward on Tuesday August 21, 2018 @09:27PM (#57171062)

      And as a bonus, your apostrophes will work!

    • My GF just game me her old laptop because it was slow and the battery was dead. I spent $25 on a battery and put Mint on there as my first dedicated linux computer. I installed a windows VM on it just in case, and so far I haven't had to touch it. Mint is rather easy to switch to, and it plays windows games on Wine better than I expected.

      It's definitely worth a try if you've got spare hardware handy.

  • Please port it to the BSDs as well, so that I can run it on this TrueOS computer

  • Good strategy for Steam. (Score:5, Informative)

    by jimtheowl ( 4200185 ) on Tuesday August 21, 2018 @09:31PM (#57171078)
    As one with a dedicated game machine that was never going to update to Windows 10, this is a very positive outcome.

    A game box with Linux will be far more useful, and likely to be on more than a couple of times a week.

    • Re: (Score:2)

      by Nidi62 ( 1525137 )

      As one with a dedicated game machine that was never going to update to Windows 10, this is a very positive outcome. A game box with Linux will be far more useful, and likely to be on more than a couple of times a week.

      Good news for me. I've replaced a couple components in my pc recently, and since I bought an OEM copy of Windows 7 years back when I first built it, it now shows as "not genuine". My HDD was also failing so I bought a new one on the cheap. I was planning to upgrade my PC later this year with a new processor but was worried I would have to upgrade to windows 10, because basically all I use it for is gaming. If Steam can now run most of it's games on Linux, I'll just bite the $40 bullet, keep the good HDD

  • Literally!

  • Side comment (Score:5, Insightful)

    by cloud.pt ( 3412475 ) on Tuesday August 21, 2018 @09:53PM (#57171150)

    I just think it's a thing of beauty what Valve has been doing for Linux gaming this past decade.

  • This is perfect for me. There is literally no reason for me to run windows except for games these days so this is great news.

    Has anyone had experience with it that can comment on the performance?

  • They explicitly say in the FAQ that while Wine and Proton work on Mac, they have no plans to support the Mac at this time - I wonder why not? Maybe they worry about confusing people where games have a Mac version but they could also run the Windows version via Proton...

    • Re:Why not Mac? (Score:4, Insightful)

      by kaoshin ( 110328 ) on Tuesday August 21, 2018 @10:52PM (#57171360)
      It seems that Apple has had a complicated relationship with Valve, with Apple previously rejecting their Steam Link app due to "business conflicts", etc. I wouldn't be surprised if this was more for business reasons than technical.
  • Adding an emulation layer has been in the GoG way of doing things a long time to deal with the ancient OS. I hope this works better for them then Crossover Linux.

  • This is exciting news! Any word on VR games?

  • Good for linux gaming (Score:5, Insightful)

    by mykro76 ( 1137341 ) on Tuesday August 21, 2018 @11:24PM (#57171468)

    Some Linux diehards will say this is a backwards step because they think developers should make native games, and they worry that this will cause developers to get lazy and not bother building for anything but Windows.

    But this is actually a good move by Valve. I've been tracking Linux games for a long time, and the rate of Linux game releases has flat-lined over the last two years. Initially Linux was gaining ground on Windows, in fact by mid-2016 Linux as a % of all games on Steam had reached the giddy height of 25.5% - there were 9000 Windows games and 2300 Linux games. Since then Linux has been losing ground again. The rate of new Linux games has been a virtually flat linear growth of ~100 new games a month. My conclusion from this is that the developers willing to make Linux releases are already doing so, and the rest aren't likely to. In contrast, Windows (and Mac) continued to show accelerating growth, pulling away again from Linux's linear growth. Some attribute this to the explosion of Windows gaming in China, and others attribute this to a boom in Windows shovelware. Regardless of the reason, only 20% of all games on Steam nowadays have a Linux version - next month we'll see the milestones of 5000 Linux games and 25,000 Windows games respectively

    I believe Valve also noticed this trend two years ago and drew the same conclusion. I don't think it's a coincidence that all the Vulkan / Wine / DXVK work started then. It's a chicken-and-egg dilemma. They had already reached saturation in winning over developers to support Linux, and now they need to win more users. With more users will come another opportunity to win over more developers.

    So yes, this is a good thing for Linux gaming.

    • "Some Linux diehards will say this is a backwards step because they think developers should make native games, and they worry that this will cause developers to get lazy and not bother building for anything but Windows."

      Theres some truth in this statement but I welcome the renewed push to get more games working on Linux. Remember that Steam is the foremost digital games distribution platform and therefore carries a lot of weight. This presumably will invigorate SteamOS usage more and with it an increased us

    • Some Linux diehards will say this is a backwards step because they think developers should make native games

      They ought to, especially if they already have a PS4 version. After all, PS4's are BSD machines, so some of the work has already been done.

    • Re: (Score:2)

      by mjwx ( 966435 )

      Some Linux diehards will say this is a backwards step because they think developers should make native games, and they worry that this will cause developers to get lazy and not bother building for anything but Windows.

      But this is actually a good move by Valve. I've been tracking Linux games for a long time, and the rate of Linux game releases has flat-lined over the last two years. Initially Linux was gaining ground on Windows, in fact by mid-2016 Linux as a % of all games on Steam had reached the giddy height of 25.5% - there were 9000 Windows games and 2300 Linux games. Since then Linux has been losing ground again. The rate of new Linux games has been a virtually flat linear growth of ~100 new games a month. My conclusion from this is that the developers willing to make Linux releases are already doing so, and the rest aren't likely to. In contrast, Windows (and Mac) continued to show accelerating growth, pulling away again from Linux's linear growth. Some attribute this to the explosion of Windows gaming in China, and others attribute this to a boom in Windows shovelware. Regardless of the reason, only 20% of all games on Steam nowadays have a Linux version - next month we'll see the milestones of 5000 Linux games and 25,000 Windows games respectively

      I believe Valve also noticed this trend two years ago and drew the same conclusion. I don't think it's a coincidence that all the Vulkan / Wine / DXVK work started then. It's a chicken-and-egg dilemma. They had already reached saturation in winning over developers to support Linux, and now they need to win more users. With more users will come another opportunity to win over more developers.

      So yes, this is a good thing for Linux gaming.

      Developers should make native Linux games.

      But to get that happening you need people to be gaming on Linux. So using a stopgap measure like running Windows games through WINE or some other system is the way you get gamers to Linux. The truth is I hate Windows, we all hate Windows but I love games, I love games more than I hate Windows so I end up using Windows.

      If you can get the numbers to Linux, the games will come.

  • OMG... (Score:5, Insightful)

    by iCEBaLM ( 34905 ) on Wednesday August 22, 2018 @12:24AM (#57171646)

    Games are literally the last bastion for Windows.... this is huge and Valve deserves our thanks.

    • Corporations around the world take issue with your statement.

      Can Wine run a custom mission critical sharepoint script?

      • Re: (Score:3, Insightful)

        by Anonymous Coward

        if your mission requires a sharepoint script then it isn't a very critical mission

        • if your mission requires a sharepoint script then it isn't a very critical mission

          Don't underestimate the stupidity of a multinational.

      • Re: (Score:2)

        by sad_ ( 7868 )

        not a windows guy, but sharepoint script run in... the browser?
        i never had a problem with sharepoint on linux so far.

        • i never had a problem with sharepoint on linux so far.

          And yet many of sharepoints functions don't even work properly even in Edge let alone anything other than IE. Don't underestimate the ability for corporations to find stupid edge cases and then implement them everywhere.

      • If someone still uses sharepoint, he have no idea what is doing nor why, he just throw some money to a problem and hope it solved it. If it is mission critical, it should never use sharepoint !

        • If someone still uses sharepoint, he have no idea what is doing nor why, he just throw some money to a problem and hope it solved it. If it is mission critical, it should never use sharepoint !

          You've never worked in a large company have you. Protip: check your logic in at the door and report to lobotimization, we will issue you your building pass when you have drooled sufficiently from the process and your eyes show no more signs of life.

    • Or any sort of decent development (like using Visual Studio) without having to pay for an expensive Mac.

  • OS/2 run windows better then windows so few os/2 (Score:3)

    by Joe_Dragon ( 2206452 ) on Wednesday August 22, 2018 @12:47AM (#57171702)

    OS/2 run windows better then windows so few real os/2 apps where made and then windows got updates that did not work any more with OS/2 windows.

    It will be nice have Linux games that are not tied to windows API's windows 10 is free and auto updates so can just up date our API's in a way that makes it not work on wine.

    • Re: (Score:2)

      by sad_ ( 7868 )

      I think Valve wants Linux/SteamOS to succeed, or at least they want it to be more successful then it is currently. A lot of people claim not to make the move because game X is not available on Linux.

      This excuse won't be valid anymore.

  • I'm not a gamer and I've never used Steam. But that's a platform where you don't own the games, right? If Steam went out of business, would you be able to play the games anymore?

    • Re: (Score:3)

      by ledow ( 319597 )

      Name any modern game that you own?

      Almost all of them are Internet-dependent, with servers run by the software manufacturers, that stop receiving updates after a few years.

      But I've have 1000 games on my account for... 14 years now? That's a better ratio than the number of games I owned in the DOS days whose disks still work or which I can get running on a modern machine.

      You're using the same argument as people did 14 years ago. The answer's still the same and well-publicised. Nobody really knows, but Stea

    • Re: (Score:2)

      by higuita ( 129722 )

      While most of the games have the Steam DRM, some do not, as long you download then, you can play then without any problem.
      If steam goes out of business, it should probably release a "permanent" DRM update, so users could still play installed games offline.

      But do not worry, checking the profits per workers, valve have higher profits than apple, it is one of the most successful companies out there

  • Better compatibility than Windows... (Score:2, Interesting)

    by Anonymous Coward

    ...for older games. I've tried many old windows games that no longer work in the later versions of windows, but work out of the box in Steam Play on Linux. So for classic gaming, Steam Play on Linux could become the platform of choice. Some of the games have been removed from the steam store because they no longer work in Windows. It would be funny if they were added back to the store as Linux only games after this is out of beta.

  • When STO went free to play, I started playing it on Linux. (though I was hoping for an eventual PS3/PS4 version). It performed okay, but as time went on, the performance suffered. And then Cryptic did a major update which pretty much prevented STO from running on Wine unless you compiled a bleeding edge wine install and engaged in the usual travails of getting it to work. I basically had to quit the game as a Captain 35.

    I installed it via steamplay on my Fedora machine and it "just worked", though I have

    • Re: (Score:2)

      by Artemis3 ( 85734 )

      I have been playing the past few months with wine staging just fine, before Valve added wine themselves.

      Probably at some point wine fixed the issues you were having. About two years ago i found a problem playing the game as well, but did try again some months later and it worked, especially when they changed the launcher and no longer showed that other Heroes game.

  • Hardly a word of praise for Valve/Steam for saying "we're tired of waiting for devs to get on board with linux support". Instead, the inevitable debate about how Wine is better, overlooking the work it takes to keep a game working in Wine long term. Linux users have bemoaned the lack of games on the platform, give them games and they bemoan the delivery method too. If you can't do it from the command line, it's just not "real" linux i guess.

  • I tried it with two games so far.
    Cold Waters worked - of sorts (no fonts in the ingame UI at all, sounds distorted - unplayable)
    OFP: Red River - didn't even launch.

    I like the idea, but so far I'll stick to rebooting to "that other OS".

    • Re: (Score:2)

      by higuita ( 129722 )

      they are only starting this, only a few games where checked. With time more requested games that fail to work will be picked up by valve and fix any wine issue or create the correct set of wine options... slowly those errors will disappear ...

      of course, not all games will work, but most will

  • I have bought many Humble Bundles over the years, and while there have been a lot of games available for Linux, there have been quite a few "steam/windows only" games that I haven't been able to play. My kids' computers run Win7. I have been disappointed that more and more games in bundles are "steam-only" instead of DRM-free like in the beginning. For the most part because my kids all use my steam account because that is what the games are linked to. But there are challenges with that approach (one log

Slashdot Top Deals

1 + 1 = 3, for large values of 1.

Close