Valve's Proton Has Brought 6000 Windows Games to Linux So Far
boilingsteam.com
boilingsteam.com
But some other enterprising threadripper user worked around that by stuffing the game in a Linux VM to avoid the rebooting.
Crazy to think that a Windows game would perform better in a Linux VM under Windows than running on Windows natively, even if the reason is that it's effectively presenting the game with worse hardware that it understands how to use more effectively.
Game Mode is a new feature in AMD Ryzen™ Master that reconfigures the platform in two key ways:
• It temporarily disables half of the CPU cores, which turns the AMD Ryzen Threadripper 1950X into an 8C16T device (like the AMD Ryzen™ 1800X) and the 1920X into a 6C12T device (like the AMD Ryzen™ 1600X). For the truly technical, this is a 4+4 CCX configuration on one die. This ensures the game encounters the number of cores it was truly designed to handle. Please note that Game Mode does not disable SMT.
• We tell the OS to use a Local Mode (NUMA) memory, which keeps a game and its memory footprint inside one CPU die and the locally-connected DRAM. This minimizes several key latency points in the system, which most games love.
My own personal examples: Halo MCC and Doom Eternal. They wouldn't launch out-of-the-box, but people just wouldn't stop trying. The GitHub issues for these games were enormous, full of information and people trying things. It's pretty encouraging.
EDIT: got fact-checked, I forgot 2016 is not native.
With the kids of how life is going faster everyday, I cannot afford to play on long stretches of time, and being unable to pause on a multiplayer game on a whim (which makes sense) makes it logical to go with a single-player game, as I can simply pause the game and pick it right up when I can, on my own schedule.
I'm glad that Valve is doing that kind of work, it benefits everyone.
I play games to escape from people.... People suck, I do not want them in my games
The cynic in me just thinks that it saves the game developers from the need to develop good AIs.
Perhaps it's just my style of video gaming... I play games to relax, definitely not to compete. People sometimes get so wound up in these games, it's supposed to be fun!
So, yes, if a game is multiplayer only, it's a reason for me not to play.
Balancing a multiplayer game is generally much more difficult than doing a single player game with AIs.
It's focused around co op and invasions and is built into the story enough that it just feels like part of the game, while again not being forced in any way.
It's entirely optional to the point where being able to invade more than a limited number of times is locked behind an obscure, difficult route in the game that's missable and entirely unlikely to be discovered the first playthrough.
There's a few different invasion mechanics based around in game covenants that provide different game experiences, both in single and multiplayer that are a lot of fun. Coop's pretty fun too. It's a pretty awesome feeling helping out another player with a boss or area they've been struggling with and I'm not ashamed to say I needed to summon a bit of help for Ornstein and Smough the first time.
But, my favourite thing I think is the asynchronous multiplayer. The notes and specters. You can leave notes with predefined phrases for other players that can be helpful, or not as well as getting small glimpses of other players 'ghosts' as they play the game, or die horribly to something.
There's no other actual interaction between players though. You can't message people, there's no lobbies, it's all very ephemeral and unnoticeable and just feels like part of the game. The only thing it really reminds me of is the counter-op mode from perfect dark, which was a hell of a lot of fun, even if it seemed a bit lacking at times.
Personally I'd love to see this system recreated and improved in other games. It's the first time i've been interested in multiplayer gaming since I was a teenager playing StarCraft and diablo.
I know someone who regularly plays grand theft auto online. Whenever i've watched them play lately I can't help but think how much better it would be if they'd built a similar system. The game would be perfect for it. The online mode it has seems pointless and pretty lazy by comparison.
Single player gaming is better than ever, and even a lot of the "indie" titles probably have bigger teams and budgets than games from whatever "golden age" you're probably thinking of.
Terraria
Stardew Valley
Those three are great for relaxing after a long day
FTL: Faster Than Light
Zachtronics games (TIS-100, Shenzhen I/O, Exapunks)
FEZ
Portal / Portal 2
XCOM
Deus Ex (Super old but quite good, I started it recently. I had best results in Proton selecting the software renderer in the first launch dialog instead of DX9)
Grand Theft Auto
Assassins Creed IV (I had trouble running this under Proton though, had to use Windows)
Planetside 2 is MMO but you can play singleplayer. Windows only unfortunately, but there's nothing else like it.
I recommend Deus Exe [0] for playing Deus Ex. And yes, it's still an awesome game.
I occasionally play a bit of Cities Skylines every few months, but if there isn't another human involved, games just can't hold my interest.
Where's the satisfaction/fun come from if you're just beating some silly algorithm?
I do play alot of simulation games, like Cities Skylines or Stellearis.
When I play first person shooters, I just like to run around and blow things up, I rarely "finish" the campaigns, for example Borderlands, Just like to run around the world and see how much destruction and havoc I can cause before I die, then start over...
I am not a completionist, I have no strong urge to "win" or "finish" the games....
I is just a way for me to turn my brain off for a few hours and escape the real world
I honestly can't think of any. If there are no goals (and goals imply obstacles to be overcome in pursuit of them) then you've got a toy, not a game.
That's probably due to Epic not having a launcher for Linux. A few months ago(?), I read it had become possible to run the launcher through Wine, but I don't think that's changed anything on the porting side.
I worry that games which are released as Epic exclusives may fall by the wayside when/if they eventually become nonexclusive.
What if the anticheat model was changed to one that detects statistically-improbable scoring (basically, a scientific model)? And triggering that would require some sort of skill verification, almost like a captcha, but for human FPS skill or whatever, generated dynamically?
Basically giving up knowing "with absolute certainty" whether there is cheat software installed or not
CounterStrike has, in times past, probably also today, used where you're aiming as a signal for whether you're using wallhacks. Like, if you're aiming and trailing directly on top of another player, but through a wall, for extended periods of time. This is statistical modeling.
> And triggering that would require some sort of skill verification
How do you remotely validate the skill of someone who is possibly cheating? Why wouldn't they just cheat at the validation? Do you, maybe, accept that they may cheat, but then raise videos of their skill checks to an enforcement team for validation? CounterStrike also already does this! They have the Overwatch system which enables specially trusted players to review gameplay footage of other players which VAC suspects of cheating.
Now, Runescape is the most explicit example of these "skill checks" I've encountered. Certain undocumented behavior which resembled botting could trigger an in-game "captcha" where you had to prove you were human. If you were, you'd often get a prize. Simple. Somewhat effective (often, people would just get around this by paying cheap labor in third world countries to oversee a hundred bots per person, and solve the captcha events when they happened. they did not save Runescape's economy from being destroyed by bots, and eventually, the game began enforcing strict value-for-value trading rules between players).
What are CounterStrike and Runescape infamous for? Cheaters and botters, moreso than most other games.
Statistical methods are a tool in the toolbox of anti-cheat systems, but they're not enough alone. They're far, far too easy to defeat; when a metric becomes a goal, it ceases to be an effective metric. If I keep a wallhack on for an entire game, it becomes very easy to detect; If I turn it on for just one kill, that one kill which puts us on the winning side of a tie, and I'm victorious, the outcome is similar, but I'm far harder for statistical modeling to catch.
If you allow everyone who cheats to play, even if they're only playing at the peak, it will break the balance of everything. The top tier games will suck because half the players are cheaters, and the lower tier games will be filled with aimbot smurfs on their way up.
Unfortunately pretty soon we are going to enter a world where the cheats can be deep learning based and entirely external to the game itself (only using video as input, transmitting raw mouse input, etc). It will be fundamentally impossible to tell the difference from human players. This will be a weird time for competitive games when it happens.
Of course with current cheating the issue is not deep learning based agents but seeing through walls or aim assisting. Those just ruin the enjoyment of the game. Similarly I loathe vs'ing an AI that uses the same methods.
Cheers
Friendly games honestly don't need it.
Most of the online multiplayer games aren't friendly, including my reference above (Super Smash Bros series).
The other option is for Apple to pull their heads out of their asses and support the cross-platform graphics API that everyone else does. But we can all guess how that will go. If you want a platform for gaming, stay far, far away from macOS.
A non-option is not an option.
It's such an easy out for developers. Why bother when people will make it work on Proton somehow and you don't have to promise anything nor do Linux support.
I finally switched to Linux (Pop_OS 19.10) after realizing Proton was good enough for all the games I enjoyed.
This is a serious question, and I don't know if it has an answer.
For example, it was easier for me to use pygame, which is based on SDL (simple directmedia layer), which is based on porting windows code.
Huh?
Building on top of SDL is probably the easiest way to make a game native on all platforms. There's nothing Windows specific about it.
Wikipedia says: "Sam Lantinga created the library, first releasing it in early 1998, while working for Loki Software. He got the idea while porting a Windows application to Macintosh."
Even the naming of directmedia suggests microsoft roots to me: direct3d directplay directx, etc.
But my larger point was that I don't know how you would create a "native linux" game - I think high-functioning games on linux use cross-platform toolkits of one type or another.
I don't know maybe you could cobble something together part wayland, part mesa, part pulseaudio, part v4l, part /dev/input...
You could make a distinction for Windows/whatever games bundled together without Wine/eON/whatever and depending what want to determine that might make sense but at that point you probably also want to exclude things like Unity that don't really do a great job at integreating into the Linux environment.
SDL can be used for porting games (ie, making them native) and that's what it was originally created for but it's not really comparable to bundling a Windows .exe with Wine, which would add a lot more complexity.
Oh come on, that's a huge exaggeration. There are thousands of native games available for Linux and Wine/Proton had nothing to do with that. Finding something to play hasn't been a problem for a long time if you are interested in a wide enough range of games.
Steam did make a big contribution to that but that was before Proton - if anything, Proton might have slowed down the number of new native releases. What Proton solves for people is being able to play specific games they want to play, like for example the latest popular AAA game that everyone is talking about - for that it's not enough if there are x% of games available no matter how big x is.
[0] http://bitpatch.com/ie_ddrawfix.html (included in the GOG.com installer for Planescape: Torment)
You are willing to bet on this? How much would you like to bet and are there any other bets you would like to make? Maybe the cubs winning the super bowl or dial up modems replacing fiber optics?
I believe this is in reference to games that no longer run on modern versions of Windows.
It's easier to test, doesn't require costly porting work if it already works, VM tech is increasingly commoditized, low licensing costs, the performance overhead won't matter, etc. Just like no one notices today if a DOS game is sold bundled with DOSBox.
The alternative would be to maintain the native Windows port of Winet that's effort - I bank on laziness with the VM bit. The fact that WSL went VM from 1 to 2 is an indicator of viability for the general idea of transparent virtualization, too.
Honestly, if you take this another round I have to assume you're being intentionally obtuse for trolling purposes.
It's Hyper-V, so you could just run Linux VM without the sugar coating.
https://virtualizationreview.com/articles/2017/02/08/graphic...
Software compositing, so you’re limited to what is practical but that’s very useful for a lot of things.
I vaguely recall (possibly correctly) that I once read it on Scott Hanselman's blog.
On top of that you add the bad stability / performance of graphic drivers on Linux vs Windows.
Edit: Since I'm being downvoted show me recent games that work without issues / tweaking etc ... ?
You are right that too many times you need to tweak stuff or install some missing 32bit library for a game but I think your 99% number is wrong.
I highly encourage you guys to check out the tech making this possible: DXVK. It's incredible what you can do with these lower level APIs. I'm not sure if this is the right word, but "meta shader pipelines" like this are absolutely the way of the future in emulation. See also: Dolphin Ubershaders.
Ubershaders: https://dolphin-emu.org/blog/2017/07/30/ubershaders/
Video here: https://www.youtube.com/watch?v=FVYprONeDtY
I, for one, am not surprised. Windows userland APIs are more stable, consistent, and well documented than their Linux equivalents.
> The only thing that matters is official support from the developer, regardless of the technology used.
The only thing that matters for what? I'm not sure what point you are trying to make.
As a long-time Linux dev (see my profile), I have also found this to be true. Linux userland APIs are unstable and change all the time. Some transitions that come to mind that have affected me personally: ALSA->pulse; libudev->libudev2->systemd; gstreamer 0.10->1.0. All of those changes required modifications to my software, and the backwards-compat tools that are provided are buggy and insufficient. Meanwhile, you can still write and run winmm[1] applications on Windows 10, and they will work in almost all cases. It's simply the case that the win32 API is more stable than Linux userland APIs, so it's entirely plausible that games will run better in Wine, which shares that stable ABI, than they will on Linux, especially as time goes on and Linux userland shifts yet again.
[1] winmm dates to the Windows 3.x days!
gstreamer on the other hand is something you can just as easily ship yourself. I wouldn't consider that a Linux userland API as much as a random library that is present on many Linux system just like some crap you'd find in system32.
I'm less familiar about the API/ABI changes in the libudev transition - is there anything there that broke API compatibility.
The "lower level" userland libraries (glibc, libGL, libX11) tend to be pretty good at maintaining backwards compat. Well, except for Mesa pulling in the C++ standard library which can be a real problem when older games also dynamically link (incompatible) versions.
And, of course, the syscall layer is stable in Linux, so no issues there either.
However, companies claim Linux is still a pain for other reasons, so I guess it is mostly about testing/support cost and perhaps OpenGL driver issues?
My cohort have a phrase they attribute to me: Linux is not ready until they get the 'Have Disk' dialog.
As for usage, linux on the desktop is between .5% and 2% market share. And there reason to suspect that Linux usage is undercounted.
https://www.netmarketshare.com/operating-system-market-share...
https://store.steampowered.com/hwsurvey/
https://www.statista.com/statistics/268237/global-market-sha...
https://hostingtribunal.com/blog/operating-systems-market-sh...
https://www.dell.com/support/article/en-us/sln286269/how-to-...
About a third of the way down.
> (Dead Cells, for example. The native port crashes the Steam overlay and lacks Steam Controller support, but running the Windows version in Proton is seamless)
Suggests the comment is about running the Windows version under Proton being a better experience than running the native Linux version.
Even without the obvious pigs like virus scanner, printer utility, launchers for other storefronts, various chrome-embeds like Slack and Spotify, I wouldn't be surprised if the Linux desktop does a better job of this.
[1]: https://cpu.userbenchmark.com/Compare/Intel-Pentium-G3258-vs...
WineHQ said you need DXVK when you want proper shadowing, but I could not get it to work.
Finally, it turned out my laptop is probably too old for DXVK (i7-4600U).
But Wine 5 can run the game without DXVK. I just needed to install it from outside the distro repo, since the distro only had wine 4
Also Tomb Raider 4 uses DirectX 7 which is not supported by DXVK so you'd need to combine it with dgVoodoo2 [0] to translate DX7 -dgVoodoo2-> DX11 -DXVK-> Vulkan, which did work quite well for me with Tomb Raider 4 and 5 while Wine's DirectX 7 implementation had rendering issues at the time.
> I needed to reclaim my Windows partition and go full-on Arch!
They tell you.
The Mac user couldn't fullscreen the game and had weird rendering artifacts.
One of the windows users had the game take 10x as long to load as it should have (commparing to mac/Linux/windows on vaguely similar hardware)
The other windows user kept dropping. Note that we were all sitting at the same kitchen table, with reasonably good wifi.
Linux worked flawlessly.
I'm sure there was some luck involved, but Linux gaming has truly come a long way from being the most finicky platform.
Sometimes official support tells nothing about runtime quality.
Every set of updates might cause a problem that I've never seen on Windows or a Mac. I had an Ubuntu machine that only lasted 2 weeks before it wouldn't boot one day after an update. Never figured that one out - it was an experiment to see how much easier Manjaro was to setup and add software to than Ubuntu. (The answer: it's much, much easier.)
Also there is a community version that includes just i3 the tiling window manager out of the box.
I just checked and it turns out it's running natively not via proton.
Not sure if any of this will be news to you, but for generally debugging:
If you run `steam` from a command line, and then launch civ 6 (or any game) from steam, it will print any errors to the terminal. Chances are it's some sort of missing dependency.
I was told by someone else that I might need to set launch options to `LD_PRELOAD=/usr/lib/libfreetype.so.6 %command%`, for whatever reason I didn't need to, but you might try that.
The two most important factors for a game to run well are 1) the version of Wine/Proton you're using and 2) the version of your GPU driver you're using.
Rolling release distros like Arch are great for gaming, since you always have the last version of Wine and of your GPU driver. It's a real pain in comparison on fixed release distros like Ubuntu, especially if like me you stick with LTS releases.
By using Proton within Steam Play you at least don't have to worry much about the version of Proton; just make sure you've not forced an old release and Steam will chose the right one for you. Same when using Wine within Lutris. Your only remaining duty is to make sure you're running up-to-date GPU drivers.
Civ 4 runs on wine, but the Beyond the Sword expo needs workarounds to work (some few winetricks commands). Does not run out of the box.
Civ 4 Colonization works out of the box but occassionally it will hang.
I have not tried Civ 3 or previous civs.
FreeCiv/FreeCol can be fun too if you don't mind the graphics. Especially the online play. The diplomacy is different.
1. The majority of the games do not support multiplayer on Linux, due to dependency on Windows-specific anticheat software.
2. Many, many of the games themselves aren't totally stable on Linux. So, expect a crash or two at critical gameplay moments.
That said, Proton is a great effort and it's great they're pushing Linux forward.
Definitely not majority. Maybe majority of the top 10-20 most popular/most cheated games? The very long tail of games works with multiplayer splendidly
There have been reports that Valve is collaborating with EAC to improve Proton support: https://www.gamingonlinux.com/articles/apparently-valve-are-...
> Many, many of the games themselves aren't totally stable on Linux.
https://www.protondb.com/ is a great database to check on the stability of games. Many, many games are very stable. Games that I happen to play regularly are more stable than Windows (especially with alt-tab and such).
I'm sad to say that Windows will likely stay this way for the foreseeable future. The additional test/QA work required in order to make additional platforms (linux, macOS, etc) have to have a business case associated with them. You could imagine the developers writing the game on linux, building and debugging/running locally on linux, but testing and shipping on windows. So even if the games work well on linux, they won't necessarily get a release.
The only thing that might change this balance would be if somehow PC-style games would target Android, or if Android would somehow become some kind of desktop OS. Both seem infeasible to me now but something could change.
Not even anti-cheat, just different implementations of things in the Linux and Windows versions. IIRC Paradox games don't have any strong anti-cheat, but Linux and Windows users can't play due to how their systems handle network time synchronization.
> 2. Many, many of the games themselves aren't totally stable on Linux. So, expect a crash or two at critical gameplay moments.
Many, many of the games themselves aren't totally stable on Windows, either. Bethesda games (Fallout, Skyrim) come to mind -- desktop Skyrim had all sorts of bugs and crashes on Windows.
And why would it crash only at critical gameplay moments? Sounds like FUD.
hah! at least back when I played nonstop twitch games there were no moments that were non-critical gameplay moments ;)
^ Aside from the regular out-of-sync issues they suffer sporadically, no matter the platform.
"Doom Eternal runs perfectly - it just have some pink flickering every minute!"
"runs perfectly - it just closes when you try to start it."
"runs perfectly - multiplayer doesn't work though."
Microsoft can change DirectX whenever they want, that goalpost is always going to change to suit them, so why even play them at their game?
Create a standard, ask Unity and Unreal Engine to support it, take a smaller cut when buying the Linux version on Steam.
They really can't. Software that uses DirectX will require a specific version of DirectX in order to have the correct ABI so that it can dynamically link against the DirectX libraries. Those versions and therefor ABIs are set-in-stone. Not to mention that a huge cross-section of the DirectX software library also distributed the required version of DirectX with the software.
Microsoft can change any FUTURE version of DirectX, but the deployed versions in the wild are out there and can't be changed.
It's called Vulkan, I believe. Or, you know, OpenGL even. Doesn't change the fact that it's the developer who will have to support it. Also doesn't change the fact that the developers _won't_ support it because of the same reasons that they don't now: it's not commercially viable. DirectX is not the problem.
So in some sense, DirectX's existence changes the economic equation, which does make it part of the problem.
These APIs were deprecated for more than a decade. DirectSound since cca 2008, DirectInput since 2002, DirectPlay since 2004.
The APIs that are left under DirectX umbrella are Direct2D, Direct3D, DXCore (adapter enumeration), DirectWrite (font rendering) and DirectXMath.
XAudio2 among several other libraries are key, even if not "DirectX". Even Microsoft points you out to them in the docs for DirectX...
While XAudio2 is a key library, it is not DirectX one, as we were talking about DirectX umbrella project. It is not as low-level library as other DirectX projects were anymore, it doesn't talk to the hardware directly. It is really just a user space library with convenient functions, made by Microsoft. It also has competition, there's OpenAL, which is similar - even if it doesn't have as nice API, it is cross-platform.
The reason is that XAudio2 (and lower level ones and other non-audio ones) is developed, distributed and recommended by Microsoft, and it is used by many major games and audio engines.
So I don't understand who cares about whether it is formally part of DirectX or not.
I didn't claim there aren't alternatives like OpenAL or Wine's XAudio2 implementation. I simply said the original XAudio2 is not portable on its own, which means you cannot simply use it in Linux, for instance.
I know of at least one game that's regularly in the Steam top 10 (Path of Exile) that is doing a port from DirectX to such a standard, Vulkan.
Not to support Linux, but because Vulkan is cross-platform, allowing them to reuse their code base for a mobile game, and also to be able to potentially support things such as Stadia. They also said this will lead to a mac port and may lead to a Linux port.
So there might actually be incentives already for game devs to use cross-platform tech, which could lower the barrier for Linux ports significantly and make it worthwile.
But my criticism to the comment above was about "just create a standard" for the linux world, as it is something trivial to do. But yes, with vulkan there now exists a standard for graphics, that can compete with DirectX again. (even though linux-foundations are not really involved directly in the Vulkan standard)
But games are more about the graphic layer, because with OpenGL there was a graphic standard before, yet still allmost no one bothered to port to linux. That changed, for various reasons. (mainly Valve and Android, I think). Also it helps, that unity for example can target linux, and their editor also now runs on it (but I don't know, how well).
When you sell a game, people expect it to just run. Windows only games have already countless bugs, making it impossible to start for quite some people. Now add to that Android (with all its different versions and vendor specific implementations) Apple with a slightly different ecosystem .. and then Linux Desktops.
Lets just say, that I am making a game. Even open source. And I want cross-platform, but don't want to get mad along the way and I want to focus on the gameplay and not platform specific code. (and did not want to use unity for various reasons)
Thats why I choose HTML5 as the platform.
Which platform specific code? With a compatibility layer and a cross-platform graphics API we're talking about a vanishingly small amount of code.
Again, do you have really first hand experience, how "vanishingly small" that amount of code is?
I have not much experience in that area, as I specialiced on the web years ago, BECAUSE I heard too much horror stories about the difference in "theoretically cross plattform" and reality.
Web is an interesting value proposition because somebody else is worrying about portability, but it's quite limiting isn't it? I mean you're limited to webGL and a single-threaded host environment. It's certainly possible to make some nice experiences within those limitations, but you're not getting anywhere close to the full capacity of a user's hardware.
Good luck, if you do. I am serious. I also think the waste of the millions of layers of the web to the hardware disturbing, but it is the best compromise I see.
"but you're not getting anywhere close to the full capacity of a user's hardware. "
Certainly not. So no, doing a graphical bombastic AAA game is not possible, but the vast majority of games is today quite doable on the web.
"a single-threaded host environment"
And fortunately today this is not true anymore. With web workers and various other approaches, you can have costly calculations in the background, but sure, this is still not the same as real multi-threading.
Doom Eternal while it works pretty well does have significant artifacts in some levels. There is also some weird bugs that don't exist on Windows and significant performance drops (game goes into single digit framerate) which again doesn't happen on Windows 10. Doom Eternal needs a high framerate to be played properly. I have a 1080Ti, I shouldn't have frame drops.
I been playing a lot of Doom Eternal (clocking over 40 hours in game) while in Quarantine and I've played it both on Arch Linux and Windows 10. My rig is pretty good (Ryzen 7 3700X and a 1080Ti).
Also if you have kernel.modeset=1 as a kernal parameter on to get Wayland with Nvidia, proton just doesn't work as it can't load up the vulkan libs (this is me going through the steam logs). I believe Pop_OS! does this, however I switched to Arch Linux now.
So I have to choose playing games with screen tearing while scrolling in Firefox or smooth Firefox with no-games.
In Windows I have none of these problems.
Nontrival answer to a nontrival question. your first order goal, gaming on linux, has a dangerous second order effect - removing microsoft market. even if you could magically solve all the problems to make a technically sound widely adopted gaming mechanism on linux, id bet MS and/or Apple take an interest in shutting you down one way or another.
I suppose that's a different topic.
The crux is making users do everything they need without accessing the parts they shouldn't.
> Proton is a tool for use with the Steam client which allows games which are exclusive to Windows to run on the Linux operating system. It uses Wine to facilitate this.
My question is, what's the "secret sauce"? If this is in fact that much more successful than Wine, what's different? Is Valve putting lots of dev time into it? Or is it just pre-configured for ease of use?
With Proton, the Windows versions of games appear in your library [1] and you just click to download and install [2]. And then that's it! No faff, no managing wine versions. If someone is intending to play a whitelisted game then for all intents and purposes their UX is exactly the same as playing the game on Windows - which is to say "very straightforward".
[1] By default only whitelisted games appear. While this whitelist is expanding, it's also possible to enable Proton to automatically run for all non-native games.
[2] A warning window will pop up to inform the user that a compatibility layer is being used, but otherwise it's identical.
Or better, enable it for the game you want to try. Properties -> use compatibility tool.
(I've had very similar experiences in a very different context with OEM Android. Small manufacturers don't screw around with the OS internals, while big shops (eg, the one rhyming with HamStrung) are more likely to change things in non-obvious ways.)
This is where Proton was a win for me. It's not super hard to make many of the popular games work, but managing the different wineprefix's or making sure some random DLL is or isn't installed was a pain. Proton keeps 'em clean, separate, and up to date.
Mainly configuration. You can almost run everything with wine but it implies quite a lot of tiny config changes and know how.
The force of proton has been to do all of that out of the box without user knowledge.
It's honestly a success, and a big one.
Over time as the code is proven in production and/or is cleaned up to upstream standards, it can be merged to upstream Wine, reducing the difference.
Also IIRC there are some other pieces that are not (yet?) part of Wine, that are distributed with it, such as the various DirectX->Vulkan translation layers.
I'm seriously considering to completely ditch Windows 10 and move my gaming to PS4/5 + Linux/Proton, but I still want to be able to stream games from the game PC to the steam link in the living room. Does this work just as well with Linux/Proton as Windows?
https://github.com/ValveSoftware/steam-for-linux/issues/6749...
By the way you can also stream PS4 games to your Linux Desktop with Chiaki: https://www.youtube.com/watch?v=4Afc_V73_3w&feature=emb_logo
The performance isn't quite as good (very close to windows perf levels), but quite a few anti-cheat systems will not work in Proton (even less so in WINE).
A lot of interesting "hacks" (sorry for calling gaming on Linux a hack) are made impractical by this.
Another is that you can buy a miner's GPU (no video output, but much cheaper) and modify the drivers to route video through integrated graphics VO. Or, modify drivers to support SLI on any nvidia card. These driver modifications require running Windows in a special mode, which triggers anti-cheats. Maybe there's a way around that. Haven't heard of it being attempted on Linux. By the way, these driver modifications are just removing artificial restrictions.
Games with anti-cheat not working doesn't bother me either as I don't play any games online anyway. So the intersection between 'games I play' and 'games that need anti-cheat' is very small ;-)
I don't think we had usable D3D10 support before DXVK, but I may be wrong.
So many games run extremely well that it's not a deal breaker for me. My last gaming rig was on Zorin Ultimate.
Tabletop Simulator, The Witcher 3, Endless Legend, all play perfectly. Haven't had the chance to try more.
Definitely a fantastic effort by Valve and Wine.
Mentally-downgrade ratings by one, as a rule of thumb.
Also, tfw the native Linux port runs worse than the Proton version PepeHands
The window creation and input event handling of Win32, together with D3D9 and D3D11 (the really popular versions of D3D), and whatever is the current audio API on Windows (this seems to be the least stable area) have proven to be quite fantastic for games, maybe the best set of low-level APIs needed by games outside of actual gaming console.
Porting those APIs to other platforms, instead of porting the games doesn't seem such a bad idea at all in hindsight.
I recently tried to run some WinXP-era games on modern hardware, and had absolutely no luck on Windows 10.
However some of the games ran fine on Wine (and 64-bit Linux).
The only downside I see to emulation is latency, but for many games this doesn't matter, and it's worthy to keep them runnable like this.
There shouldn't be significant latency issues, unless there is large amounts of (CPU) work that's required to make large data structures compatible(for a silly example, imagine that the texture formats are different and you need to convert between them). Or if you need to simulate a single function call in a tight loop with several calls.
But the overhead is usually not much more significant than what you get when you import a library to call OS functions on your behalf, versus calling them yourself.
That said, I think it's great that Valve contributes. It might be naive though, to believe, that they'd do any such thing, if the license did not force them to. I am quite sure, that they'd see some kind of advantage to take, if those contributions could be limited to only their own platform.
Proton has been a perfect experience for me.
I know a few designers & video editors who use passthrough to run Adobe software on their beefy workstations, which I would also prefer as I'd rather not use multiarch on my linux system.
[1] https://appdb.winehq.org/objectManager.php?sClass=version&iI...
Just imagine if DirectX 13 was XboxTM Game Store exclusive...
Valve is expanding into the linux/unix space because Microsoft has set up their MS Store, which threatens to undermine them directly.
I know many Linux users who have abandoned competitors (GOG..) for Steam due Linux support.
Is steam selling linux games with proton as Linux games? Or do you have to buy the windows version and run it with proton.
I got black Mesa on Linux from steam (works great), but is that a proton game? Last time I browsed Linux games on steam most seemed like they were indie with very few aaa titles..
I do feel Linux has arrived.
Black Mesa uses the Source engine for which Valve created their own ToGL wrapper but it's compile-time and much smaller than Wine.
[1] www.protondb.com
EDIT: Clickable: https://www.protondb.com
VR games are a large omission.
It's a fairly large underserved community when it comes to gaming, and they're practically all Linux boxes, and the latest gens are perfectly capable of modern 3D gaming, if not all the AAA titles.
It's a classic chicken-egg problem.
I have a game on Steam, it builds and runs on ARM/RPi just fine, but there's no ARM in the list of architectures on Steamworks because the client doesn't support it. So I don't bother shipping the ARM build despite having one here and one of my artists using an RPi4 as their primary desktop with a functioning build of the game for testing.
We're talking about commercial interests here. If a game has been ported to native linux/SteamOS, it's likely just a recompile away from having ARM support. If the Steam client were made available to Pi users the demand would appear on the store for more ARM-compatible games and we'd all immediately jump on the opportunity for more sales from practically zero effort.