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

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.

Comments

Works

[TAiNiUM]

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

[Anonymous Coward]

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.

Re:Works

[Anonymous Coward]

Read it and weep faggot.

Re:A better replacement for Wine?

[TAiNiUM]

Not in that general of a sense, no. It is still Wine but now with significant resources invested in gaming-specific technologies.

Good strategy for Steam.

[jimtheowl]

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:Upstreaming

[Shikaku]

All changes are upstreamed to the Wine project as they said in their FAQ, located here: https://store.steampowered.com... internally it's their packaged version with changes for Steam specific support but otherwise just Wine. Open source, and sources here: https://github.com/ValveSoftwa...

High level

[DrYak]

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 ?