TR Forums

https://steamcommunity.com/games/221410/announcements/detail/1696055855739350561

The performance improvements are nice and all, but the real story is in ease of use. The baseline knowledge required for Wine gaming is now the same as for native Linux gaming. Given how they've built it, I expect that official support list will balloon very quickly, and even off those rails I'll probably be able to use it instead of running Steam in Wine most of the time.

So far, my experience with it has been: opt into Steam client beta, check the "enable Steam Play for all titles" box, install Mirror's Edge as if it were a perfectly normal native Linux game on Steam, everything Just Works. If that experience holds across as many games as it might, it's the biggest single boost Linux gaming has ever gotten with one software release.

I'll post an update here when I've tried more games in it.

That's pretty cool. Please do post an update. No disrespect to the developers which have brought Wine this far, but I have to agree that if Valve can integrate Wine in a way that doesn't require the jumping through of many hoops, then that's a pretty big deal.

That's friggin' awesome. If this works well (and the performance isn't utter crap compared to native) I can see myself building a Linux steam play server. Windows is a pain in the ass to run that way with the screen locks, updates that reboot randomly, etc.

I've just started trying this out. Setup was very straightforward, following Valve's own instructions worked as it was supposed to. So far, the only Windows game I've tried to run with it is "Sam & Max Season 3, Episode 1" - not exactly taxing the system. But, it does install and work perfectly, and there's a lot to be said for just making things work.

From what Valve has said about this, Steam Play titles that are whitelisted to work on Linux will be fully and actively supported, which will be fantastic. As someone who already does most of his gaming on Linux, this just gives me that much more to play.

Also, I haven't fired up Mirror's Edge in years - installing now ...

If the performance hit is acceptably small, this makes a lot of sense.

I can't help but be a little disappointed though, since this likely means they're throwing in the towel on getting broader native Linux support from game devs. But that was a high hill to climb from the get-go.

I tried a couple of the supported games last night: Ultimate Doom and Quake. The OpenGL version of Quake would launch and immediately disappear, while Doom would let me launch in both "normal" and "classic controls" mode, but both seemed identical so I suspect that wasn't working either.

I'm tentatively blaming my video driver, which is the open-source Radeon one that Kubuntu defaults to. I've had the proprietary driver working before but would rather not use it because it causes display corruption when I run a screen reddener for nighttime use.

I tried STALKER on my RX-460 and it was like running native. World of Warships runs, albeit slowly on my RX-460, but it does in windows as well. No rendering artifacts which was cool!

For anyone running radeon GPU's, the AMDGPU (open source driver) is the best driver choice at the moment, and the one most supported by AMD.

Make sure you add the PPA's for Padoka (mesa):
$ sudo add-apt-repository ppa:paulo-miguel-dias/pkppa
$ sudo apt-get update

and Ukuu (kernel):
$ sudo apt-add-repository -y ppa:teejee2008/ppa
$ sudo apt update
$ sudo apt install ukuu

Lots of goodness in the newer mesa releases and the latest kernels for us. Once you get ukuu installed open the program and install a newer kernel like 4.17.x or 4.18.x. Mesa will update automatically.

just brew it! wrote:

I can't help but be a little disappointed though, since this likely means they're throwing in the towel on getting broader native Linux support from game devs. But that was a high hill to climb from the get-go.

The other side of the coin is this could be a good enough stepping stone to get the target audience big enough that the devs feel it would be worth their time.

Usacomp2k3 wrote:

just brew it! wrote:

I can't help but be a little disappointed though, since this likely means they're throwing in the towel on getting broader native Linux support from game devs. But that was a high hill to climb from the get-go.

The other side of the coin is this could be a good enough stepping stone to get the target audience big enough that the devs feel it would be worth their time.

Worth their time over just polishing the Windows version and selling it to both audiences? If it works and runs acceptably, who cares whether games are native or not besides a small cadre of the platform-obsessed?

Kretschmer wrote:

Usacomp2k3 wrote:

just brew it! wrote:

I can't help but be a little disappointed though, since this likely means they're throwing in the towel on getting broader native Linux support from game devs. But that was a high hill to climb from the get-go.

The other side of the coin is this could be a good enough stepping stone to get the target audience big enough that the devs feel it would be worth their time.

Worth their time over just polishing the Windows version and selling it to both audiences? If it works and runs acceptably, who cares whether games are native or not besides a small cadre of the platform-obsessed?

That's pretty much what happened to OS/2 back in the Windows 3.1 days; it ran Win16 and DOS programs just fine so there wasn't much motivation to make native programs for a niche platform, and IIRC some of the native apps (like Lotus 1-2-3) were poorly optimized and much slower than the Win16 equivalent.

Kretschmer wrote:

Usacomp2k3 wrote:

just brew it! wrote:

I can't help but be a little disappointed though, since this likely means they're throwing in the towel on getting broader native Linux support from game devs. But that was a high hill to climb from the get-go.

The other side of the coin is this could be a good enough stepping stone to get the target audience big enough that the devs feel it would be worth their time.

Worth their time over just polishing the Windows version and selling it to both audiences? If it works and runs acceptably, who cares whether games are native or not besides a small cadre of the platform-obsessed?

The problem with this is that when MS releases new DX extensions, it'll take months (if not years) for Wine to fully support them in a stable release. It cements Linux's status as a second-class gaming platform in perpetuity. Which is not to say that it wouldn't remain a second class citizen anyway; but this puts the nail in the proverbial coffin.

just brew it! wrote:

Kretschmer wrote:

Usacomp2k3 wrote:

The other side of the coin is this could be a good enough stepping stone to get the target audience big enough that the devs feel it would be worth their time.

Worth their time over just polishing the Windows version and selling it to both audiences? If it works and runs acceptably, who cares whether games are native or not besides a small cadre of the platform-obsessed?

The problem with this is that when MS releases new DX extensions, it'll take months (if not years) for Wine to fully support them in a stable release. It cements Linux's status as a second-class gaming platform in perpetuity. Which is not to say that it wouldn't remain a second class citizen anyway; but this puts the nail in the proverbial coffin.

"Second Class" implies a level of undue discrimination against Linux. I would term it as "receiving resources proportionate to its user base of gamers."

It may be a second class platform but it's getting a LOT more attention these days.

Kretschmer wrote:

"Second Class" implies a level of undue discrimination against Linux. I would term it as "receiving resources proportionate to its user base of gamers."

Fair enough. But that leads to a chicken-and-egg situation.

And yes, the near-endless churn on the GPU driver front didn't help either. (This finally seems to be improving somewhat.)

Wine CPU performance I had been thinking was very impressively close to parity in 2018, but it just turned out my CPU has been effectively running at ~3/4ths speed when in Windows. That might be a decent measure of the slowdown. GPU-side, I think AMDGPU is a bigger issue than Wine most of the time (IOW everything's pretty much fine), but there are edge cases. I often enough have to turn down some particular setting to get a game running well.

As for Steam Play, esync may noticeably help out the CPU side and DXVK may noticeably help out the GPU side for DX10/11. DX12 support is all thanks to Valve AFAIK, so I've got no idea there. It does not appear to include Gallium Nine (probably because it doesn't work with Nvidia), which means a bit of a regression from the best Wine has to offer on DX9.

I'm not worried about Linux ending up like OS/2; gaming is a sideshow as far as most already running Linux are concerned. It is a big reason that a whole bunch of people who are fed up with MS stick with Windows anyway, though. Wine used this way can be fairly invisible to users, and if devs care is a much easier target than a native Linux port. It also suits Valve's goals just fine. I don't think Wine being the default way to game on Linux would be a terrible thing, though native game releases are far beyond that already.

It'd be interesting to know how many man-hours it took to get Steam Play's DX12 support functional. I'd guess that with Valve's resources DX13 can be running pretty soon after release if they deem it worthwhile.

Anti-cheat and DRM seem to be the biggest remaining roadblocks for game support in Wine, and there's probably no way for Wine to truly get around that problem. It'll also be really tough for game devs to target Wine support with that unless anti-cheat vendors start going out of their way to support Wine (which sounds like a PITA given what they're doing and I doubt they will). That's a good incentive for native Linux gaming to still be a thing, and to even receive a lot more attention if easy-to-use Wine brings more gamers to Linux.

bthylafh wrote:

I tried a couple of the supported games last night: Ultimate Doom and Quake. The OpenGL version of Quake would launch and immediately disappear, while Doom would let me launch in both "normal" and "classic controls" mode, but both seemed identical so I suspect that wasn't working either.

I'm tentatively blaming my video driver, which is the open-source Radeon one that Kubuntu defaults to. I've had the proprietary driver working before but would rather not use it because it causes display corruption when I run a screen reddener for nighttime use.

I RTFM'd and my copy of Mesa was slightly too old. They've got more information here about how to get Proton working correctly: https://github.com/ValveSoftware/Proton ... PREREQS.md

Seems fine now.

These games are a relatively tough sampling for Wine to handle. I wanted to give it a good workout. Skyrim and ME2 are easy, Deus Ex is theoretically easy, DX:HR and Mirror's Edge are easy to run but tough to run well, I've never gotten JC2 or Worlds Adrift running in Wine (the former because last time I tried it Wine didn't really do DX10 yet), and TABG is no longer likely due to anti-cheat. This sampling is pretty DX9-heavy because I haven't yet gotten around to buying too many more recent games (I've got plenty of Steam backlog without buying more) and most of them I do own either have native Linux versions or are 30+ GB downloads.

On average, it's about as expected. There's room for improvement and troublesome games continue to be troublesome, but it does bring a lot of games into an entirely different class of ease-of-use.

This is with an R7 1700, RX 480, AMDGPU non-PRO, and 1440p.

It stores the Wine prefixes in Steam/steamapps/compatdata/[appid]/pfx/, one prefix per game. Even if you're not tweaking anything to do with Wine, that's useful to know for ini editing and the like.

==== ==== ==== ==== ==== ==== ==== ====

Deus Ex (the original): In the main menu the mouse bindings are wonky (left movement moves up and left, right moves up and right, down moves down and right). Weird, but once in-game everything's flawless. Every time until now I've tried to play it (including on Windows) something or other has been problematic, so this is a good showing.

DX:HR: It's good with Gallium Nine, but without it it's still stuttery enough to be barely playable, even on minimum settings. That's a failing grade in Steam Play.

Skyrim (non-SE, no mods): ~60 fps (max settings aside from shadows and reflections) is a bit weak, but latency and smoothness are top-notch. I don't remember Skyrim ever being close to this stutter-free even on Windows (though admittedly the last time I tried that was on a system with a lot less CPU power).

Just Cause 2: It looks like there's a bug in Steam Play's setup of the Wine prefix. It's probably easy enough to fix by Wine standards (though I haven't tried), but by the kind of ease-of-use standards we're looking at here it's a failure.

Mass Effect 2: Flawless.

Mirror's Edge: Stuttery, but I haven't yet found a way to play it that isn't, including on Windows. It's good enough for casual play and about as good as on Windows+Nvidia, but significantly worse than Windows+AMD and even that is pretty shoddy for speedrunning.

Totally Accurate Battlegrounds: They added anti-cheat (EQU8) since I last tried this, and that doesn't seem to get along with Wine.

Worlds Adrift: EAC works, so maybe my previous thoughts on Wine and anti-cheat are off-base, but it looks like it messes with DXVK, hanging the system's graphics badly enough that ctrl-alt-F2 doesn't help. I'm not inclined to blame DXVK; it isn't exactly the first time Worlds Adrift has done things like this.

Tried another Windows game, "A Hat in Time" (got it from Humble last month). Works perfectly, using a Steam Controller as input (it's detected in-game as an Xbox 360 gamepad, but that's pretty normal), and even got some achievements and a trading card for playing a bit.

The only difference I'm seeing (with my huge sample size of 2 Windows games so far) in terms of user experience is that the games take longer to start than I'm used to - 10 seconds to actually see the first game screen, as opposed to 1 or 2 when running something native. Once in the game, everything appears to be normal.

Chuckaluphagus wrote:

The only difference I'm seeing (with my huge sample size of 2 Windows games so far) in terms of user experience is that the games take longer to start than I'm used to - 10 seconds to actually see the first game screen, as opposed to 1 or 2 when running something native. Once in the game, everything appears to be normal.

You're essentially booting up reverse-engineered clones of several Windows subsystems in addition to the game itself, so this is not surprising.