I LOVE Proton. About 85% of my Windows games just... work. And probably 75% of the 15% that fail initially only require a little tweaking to make work.
My only complaints are that steam uses arbitrary numbers instead of human readable labels for emulated AppData folders. It can be time consuming to locate a save game file. Also Streaming cross platform isn't a pleasant experience yet but it's getting better and I really appreciate the feature. My final gripe is that when adding media to a Steam chat on Linux the file open dialog does not cache the last folder you visited and doesn't support multiple files. This compounds the first problem I listed making it EXTREMELY time consuming to share multiple game files with friends quickly.
IIRC, the folders that contain a Steam UserIDs save game data are named after the game's Steam AppID. You can look them up here (https://steamdb.info/apps/). I admit it's certainly not a solution to the discoverability problem when navigating a filesystem, as there are over 100,000 AppIDs and growing at this point.
> My only complaints are that steam uses arbitrary numbers instead of human readable labels for emulated AppData folders.
Yeah, it's a chore. Sadly there really isn't a better option. The only option I can think of is to use the game's localizable name, but that gets pretty ugly very quickly (consider the ".HACK" series). Another option would be to re-use the game's data folder name, but that gets hairy with stuff like DLC and shared depots.
It's not really intended for users to be digging around in there, so... it is what it is.
They could use a scheme like `AppID-name` where `name` is the sanitized lower-cased title, e.g. `50631-hack`. From Steam's perspective it doesn't really make any difference, it could just ignore everything after the dash, but at least it gives the human an idea of what's in there.
This was what I was going to suggest. This is what the Nix package manager does where folders are hashes of the build dependencies. In v2 they suffixed the package name and version number.
I've noticed that people tend to build systems like these using only hashes and it's only later in the project they realize it sure would be nice not to have to look this up all the time.
Inside of steam, you can click on a game to browse local files. It works on Linux anyway, just opens my file browser to the right place.
I agree it should be rare, though I have had to do it for stuff that I wouldn't consider to be too advanced (using mods) but it's fair to say that it's still uncommon in the grand scheme of things since most games have a decent UI for handling mods already.
I maybe need to get to a game folder... three times a year? The only time it was more than that was when a modder I really liked stopped publishing releases outside of github so you had to copy them to the right place manually.
> Inside of steam, you can click on a game to browse local files.
This gets you to the game's install directory, not to the corresponding Proton prefix which contains the Windows user profile directory with the save file.
The ideal for me would be to keep everything pertaining to a game - the game itself, Wine prefixen, Workshop items, screenshots, etc. - in one folder for each game. Like, how hard is it to put everything for, say, Kenshi into "C:\Program Files (x86)\Steam\Games\Kenshi" or "~/.local/share/steam/games/Kenshi" (with "compat", "workshop", and of course "game" subfolders for the Wine data, Workshop items, and game data, respectively)?
Like, even if it ain't meant for users to go rooting around in Steam's folders (yet that's a very common occurence anyway), you'd think it'd be the sanest approach for developers, too (both of Steam and its games), no?
THey could just use the numbers as a suffix to a sanitized version of the name and everybody wins, but that would require them to think seriously about usability.
It's even worse with Workshop items (on the various occasions where you need to make edits or otherwise troubleshoot 'em), since you need not only the game's AppID, but an even longer numeric ID for the Workshop item itself.
Luckily this is the same as the one in the item's URL for its Workshop page, but it's still annoying to have to copy and paste that into something just to see it (if doing it through the Steam client).
Workshop is one of those places where Proton doesn't work so well in my experience. I end up with lots of crashes and failure to start when trying to enable workshop mods in most games.
I've had the opposite experience, with Workshop mods usually working fine as long as the game itself is working fine. It's usually just the mod creation tools that are really sketchy under Proton (current head-against-the-wall experience is with Kenshi, where the Forgotten Construction Set will spontaneously freeze after a couple minutes under Proton).
I am a recent convert and can confirm. I am on PopOS and 9/10 , it just works.
Right now my only issue is with Fallout 4 sound disappearing, but I am slowly working on using qemu with Win10 image. I am genuinely thrilled, because I may finally be able to ditch windows ( from dual boot ).
Proton is the reason I moved from a Windows + MacOS machine to GNU/Linux full time. I understand the concern that some hardcore enthusiasts might have about it making devs lazy when it comes to developing native ports but to be honest I don't care. I am just glad to have a simple method of gaming on GNU/Linux. Proton plus Lutris and the slew other tools that have come out in recent years has made the transition to GNU/Linux very easy and has opened the door for many who were curious but scared of the learning curb.
I choose to irrationally support Linux, because I like Linux. There is literally no financial incentive for me to do so. We were recently debugging a newer build on Linux, which was inexplicitly crashing on a players machine, while running great in the testing environment. This was causing a major headache as the game needed to ship that day.
We had another Linux volunteer test it out on his mostly vanilla Ubuntu setup, and it worked great. Ended up creating a chart of all the available testing configurations, e.g. comparing drivers across all the available environments. The supposed blame ended up being a statically linked library on his system. Funny thing is the tester who was crashing was enjoying the game in Proton while I was debugging the Linux build.
Thanks. It's called BadLads, it's all about multiplayer roleplay, where each player has their own job. The games about to get giant procedural cities (with full interiors!) and native virtual reality support. Here's the last devblog, although a bit dated:
https://devblog.chemicalheads.com/posts/upcoming-update-teas...
> making devs lazy when it comes to developing native ports
Is this first order thinking? Whereas second order thinking might be "with Proton enabling an order of magnitude more users that enjoy PC gaming to move to Linux, studios might consider improving the PC gaming experience further with more native ports/testing directly on Linux?"
I don't know if that's how things could play out, but it seems logical to me.
Because Proton creates a dangerous market pressure. The linux+proton user is the ideal customer for a game developer: someone paying full price but to whom you owe absolutely no obligations. Bug reports from Proton users can be safely ignored. They should feel lucky if the game even started under their not-supported hack of an operating system. But those who purchase a native linux client (KSP, Factorio, Prison Architect etc) have to be offered at least a modicum of support.
I like proton. I really like being able to play subnautica. But every time a game updates I cringe a little because I know any new linux-related bugs are more my problem than theirs. I would much rather have game developers treat linux users as full customers.
I have bought many native Linux games that simply don’t launch, but run perfectly in Proton. Companies also stop updating their Linux ports often. There is so little market pressure to support Linux in the first place that Proton’s effect is basically irrelevant. Most Linux ports sucked anyway and often Proton performs better including with things like Unity games, so no big loss.
> I have bought many native Linux games that simply don’t launch, but run perfectly in Proton. Companies also stop updating their Linux ports often
They also stop updating their Windows versions, the main difference is that Microsoft cares a bit more about backwards compatibility than the vast majority of Linux desktop developers.
That's true but I was referring to games that continue to add new features and improvements to their Windows client, but leave the Linux client on an old version, which is a separate issue. With online games this sometimes even means that Linux users will no longer be able to play with Windows users.
On the other hand Wine probably has better backwards compatibility with old Windows games that Windows does in many cases.
It does. I've got older games from the Windows XP days that had issues with Windows 7 even with the compatibility mode. My Linux box with proton was able to run it, ironically enough.
Try the KSP linux client. It is far more stable than the windows client. Heck, I've found it more stable than my outlook on my work machine, more stable than MS office on MS windows.
Port, native client, whatever. Most native Linux versions do not work well at all, and many that do have very low performance OpenGL renderer rewrites that cannot compete with DXVK.
There are obviously exceptions, but IME they are quite rare.
Conversely, if proton is creating a much larger linux gamer market (its on of the big reasons I switched to linux as my daily driver), might this new market not soon be able to exert pressure on developers for first-class linux ports?
Bit of a potential chicken and egg problem with developers supporting linux natively that proton might help solve.
I don't want ports. I want proper linux clients developed alongside the other clients, which is relatively easy under tools like unity. Every developer gives lip service to "maybe linux later" but they never do it. If they aren't doing cross-platform development from day one there is next to zero chance of them doing it later in the dev cycle when such things are far more expensive.
What would really light a fire under developers would be for people to run away from windows for other reasons. A few more privacy fiascos. Yet another attempt at "versionless" windows. Another Vista. Only when users actually dump windows for other reasons will major game developers truly care about linux.
It's been 30 years. This was nothing but a pipedream before Proton came along. It's probably still a pipedream, but at least we'll be able to play more games on Linux now. Don't let perfect get in the way of good.
There's never going to be a mass exodus to Linux. People have been promising the year of the Linux desktop for as long as Linux has been a thing. It's time to find a way to coexist, and Proton is so far one of the best solutions for gaming.
It was more than a pipe dream. The mobile game revolution happened long before proton. Windows penetration in mobile gaming is <1%. Now we have some interesting Mac chips that will require cross-platform development too. And many of the best linux games (KSP) were popular before proton. WINE/Proton is a force, but is not the only player in the cross-platform gaming space.
Relatively easy to build perhaps, but you still need to have a QA team for it, support it after release etc...
That's also assuming they're using an off the shelf engine that is also bug free on those platforms. Both unreal and unity aren't at the same level on Linux as their windows counterparts, and Lord knows I've tried . There's always one more thing that doesn't work and requires workarounds.
I don't think anyone wants ports. I use linux as my home machine now and the desktop application delivery on linux is pretty fractured (flatpak or snaps or debs..). You kinda wish in the small desktop linux market there would be one distribution method to rule them all.
we can't even get MS office or Adobe to port to linux. Open Source coders have done well to get us somewhat working alternatives. (LibreOffice, Krita and Blender come to mind)
I've had good luck with Proton. It makes me not have to use a second machine for games.
I think people are vastly underestimating how much gaming sucks even on Windows. Nier: Automata still hasn't received a single PC patch to my knowledge. Many of the games on Windows are ports as well, such as Nier.
The PC has largely taken a backseat to consoles. It's a bit much asking for Linux native, let alone, Linux ports.
Since you mentioned Nier: Automata, I'll just add that I've been playing it with proton for the past 2 weeks. I'm at ~20 hours of playtime and it's been flawless so far (without resorting to any 3rd party patch like FAR).
steam has it as mostly positive, so I'm not surprised. But who knows how many are using the fan patch and how many are not. But many many of these reviews are complaining about the port and it all seems YMMV.
I'm just using this as an example. If Windows isn't getting a port or getting shit ports, Linux is not getting native. Sorry to burst anyone's bubble here.
Showing support for linux is great, but what about DRM? What happens when the desire to prevent piracy of the windows client means attaching software that will never in a million years run on linux? DRM is why linux users have basically given up on ever getting access to games from the largest developers.
I have personal experience with that problem.
Recently I had to install a secondary windows boot just to play W40K Battlefleet Gothic Armada in drm-protected COOP!
But DRM is a problem in and of itself. Something which linux gamers can't even change by refraining from buying, with their mighty ~1% market share.
Also, the companies who rely that heavily on drm are not really in the business of providing native linux clients either. So proton can hardly be a hindrance for adoption here...
I'd rank anti-cheating as a problem with a similar effect but without the ethical concerns of DRM. Few customers want DRM, but nearly all customers want fair games, yet anti-cheat is just as hostile to "non-intended" environments as DRM.
The difference between DRM and anti-cheat is just semantics. The license says "do not cheat" and the software enforces that license = DRM. But lots of players really don't care about "fair". Any game with a large mod community, mostly single player games like KSP or minecraft, generally stays far away from any form of DRM. The entire concept of "cheating" doesn't really exist in such games.
> Any game with a large mod community, mostly single player games like KSP or minecraft, generally stays far away from any form of DRM.
Many major first person shooters stand as counterpoints to your claim. Most Valve games for example are incredibly mod friendly, at the same time Steam was a pioneer in online DRM and Valve Anti-Cheat (VAC) is generally reasonably effective.
Even games where the anti-cheat isn't as mod-friendly as Valve's often offer modes where the game can be launched with anti-cheat disabled but you lose access to public matchmaking and ranked play, only being able to play on private games and/or servers that have turned off anti-cheat themselves. The PC port of Halo does this well.
> The entire concept of "cheating" doesn't really exist in such games.
For the record Minecraft does in fact have anti-cheat, but it's mostly just about illegal movements versus anything else, flight without creative privileges in particular. Anything beyond that is up to the server operator and their chosen plugins. Cheating is still definitely a thing, at least when playing survival with other people, but what defines cheating is up to each group to decide for themselves.
---
DRM and anti-cheat do have the same big picture goal in the end, prevent the user from tampering with the application, but I do agree with the above poster that it is very different ethically. We all want our ranked play to be free of cheaters.
> The difference between DRM and anti-cheat is just semantics
Not really - DRM = anti-copying/anti-piracy, anti-cheat is self-explanatory. Both sometimes employ similar strategies (anti-tampering/poking around with executables, linked libraries or memory), but they are not the same thing
That's one view, but I'd argue that they are both variations on the general problem of "how to run software on a computer without letting the owner of that computer actually control the software". When it's against piracy, the goal is to make sure that the software can refuse to run if it's not correctly licensed or to make sure that the user can't send its output to a recording, and when it's against cheating the goal is to make sure that the user can't modify or view the game state except through the standard game UI, but both revolve around denying the user power over software executing on their hardware.
The big difference is that anti-cheat usually applies on company property, i.e. on their servers. The most common punishment for tripping anticheat is a ban from online services of some kind.
That's true but I was referring to games that continue to add new features and improvements to their Windows client, but leave the Linux client on an old version, which is a separate issue. With online games this sometimes even means that Linux users will no longer be able to play with Windows users https://www.lustvollerjonas.com/ .
On the other hand Wine probably has better backwards compatibility with old Windows games that Windows does in many cases.
Alternative outcome: At least some developers who are passionate about helping users who ask for help may look into issues with games crashing on proton.
I get your concern but I think it's a form of "perfect being the enemy of good". Your stance boils down to "don't enable effective workarounds to play non-linux programs on linux" because there is a chance it will reduce the already rare motivation for devs to make native builds on Linux.
I think the opposite might end up being true. With a critical mass of users on Proton, developers end up being pressured to make sure their games work properly in it. When a substantial number of their users have a problem running a new version of their game, even on an unsupported platform, they tend to do something about it. There have been a few instances of this happening already for some high profile games.
Frankly, if you don't care about your customers, you can ignore all their bug reports. Whether they're on a supported platform or not doesn't seem like it would matter much. The real question is whether there are enough Proton-using customers to warrant paying attention to their woes.
This is 100% true. So far i have not even received a answer to 5+ reports about issues running with proton. Even thought most are simple fixed unity quirks
If game developers provide official support for proton I would be more than happy. If the engine they are using doesn't support an automatic Lnux build I cannot insist that they should do a native Linux build. It's too much work for little gain. However, if they support proton officially I can live with that because the expected amount of work should be insignificant. 99% of the problems I have encountered were because of anticheat, broken launchers and a video game franchise using some weird proprietary microsoft video codec that literally no other platform supports. Fixing a launcher is not much work. Fixing video codecs is not much work. Anticheat software should support proton. It's not too much to ask.
It does create a dangerous market pressure, but entirely by accident. Valve has developed an amazing piece of software in Proton and made it freely available, but offered no support for developers. Proton is an enormous library papering over an equally enormous API gap between Windows and Linux. Normally when game developers use such components (like engines) they pay a licensing fee, so that when something breaks, if it’s the licensed component’s fault, they can expect support in fixing issues. Since Valve doesn’t offer a paid support option to devs, they are in a difficult position - Proton is by far the easiest way to get games running on Linux, but can’t be officially supported without incurring the cost and overhead of bringing on a team of Proton specialists to ensure compatibility.
I’m not in this area professionally so maybe I have a few things wrong here.
Proton is not a ground-up valve product. It is an implementation of WINE, a project that has been around for a long while. Valve made it pretty and easy to use, integrating wine into their launchers, but it isn't entirely their project.
Valve has been contracting https://www.codeweavers.com/, the main people behind Wine, a good deal, so they do deserve more credit than at might first appear.
Native Linux games break too, especially older ones. I have had to switch to Proton for several games I used to run native because their native version has stopped working after some library change.
At this point I have more faith that a game with solid Proton/Wine support will work on the long term than a native one.
There are many exceptions in both directions of course, this is just my personal experience with the games I happen to be playing.
It wouldn't be the worst thing in the world if Proton/Wine became the standard supported runtime for games.
The solution here is unbinding native support from native compilation. It seems to me that the ideal world is someone who (or someone's contractor who) provides a proton wrapper for a game that works with zero bugs compared to running on Windows, and then either patches the bugs clientside or provides patches for wine/proton.
This seems like right approach, although I'm not a purist anyways. I have a personal policy not to buy games unless they have Linux support, however I have decided that games that officially support Proton are good enough. At the end of the day I just expect that it works, if the performance or something is terrible I can always refund it.
I don't really care what tools/APIs the devs use as long as it works well. If they target Windows APIs but use Wine that is fine with me as long as they test it and make sure it works.
And as you said, if this allows more people to game on Linux it makes the Linux experience more important to the game developers. If they decide at some point that Wine is holding them back they will make that switch when the investment makes sense. I think that the most important thing to the long-term success of Linux gaming is ensuring that companies think they can make money there. If they think they can make money then they will continue to make games and put effort into making sure that the games work well.
The problem is always market share. Unfortunately Linux has and most likely will always be a niche desktop product. For that reason when devs are developing a game, the question is always "should we spend X amount of time for 0.5% of the userbase" and often times the value proposition just isn't there.
Gluglu with their chromeOS has pushed the linux adoption line quite rapidly.
Valve finally making SteamOS a viable product is definitely going to impact the change significantly.
The only reason I still keep Windows dual booted is the Office suit, which is still unbeatable.
Sadly true. I get by with LibreOffice, but I'm not a power user at all, yet I still hit usability quirks and bugs all the time. For stuff that just needs to work, I use Google stuff instead, if begrudgingly.
> studios might consider improving the PC gaming experience further with more native ports/testing directly on Linux?"
that does not match the historical experience of studios doing absolutely terrible ports of console exclusives to MS Windows, stuff like games where you can't rebind your keys and a qwerty layout is assumed, FPS is fixed at 30, etc etc
Proton will not make devs create Linux ports, but it will increase the user base and other devs might consider creating Linux ports for their non-game products.
Not for me personally, but I have seen a lot of kickback from some people on other forums. Although that could just be the audience. But I honestly think that if Proton gets 80-90% of the work done for devs most probably won't bother trying to make a native port, but I also go back and forth part of me likes to think that if there is a strong non-windows or macOS alternative companies will pay more attention to it.
I dropped the "native Linux or nothing" mindset sometime in 2013 when I saw the harm it did to developers. As a disproportionately vocal minority comprising <1% customers but >50% of bug requests, making Linux users happy was pretty literally taking food out of some dev's mouths.
The two goals that actually needed to be achieved were preventing market monopolies and enabling smaller devs, which platform agnosticism has been a welcome and necessary side effect of.
i) Reducing the resource overhead required to publish and support games is make or break for indie/small devs. Just by being Steamplay/Proton aware, compatible games don't require exclusive support, allowing devs to focus on content and expansion instead of learning quirks of all different distro just to be able to support that one user on Hannah Montana Linux. Helping individual customers feels great, but it can become a deadly rabbit hole.
ii) The market aligned against publishing monopolies, which Valve isn't singlehandedly responsible for but has been a major contributor to. Linux native was just a way to get devs and publishers to realize that they couldn't and shouldn't fall prey to the exclusive marketplaces on the rise at the time like GWFL that would only reduce choice and availability for customers and non-AAA devs in the long-term. Breaking OS dependence was key in this.
I think we ultimately want Linux to be able to do whatever we want, be that running video games, powering Mars rovers, or running our HPC clusters. Once software can be run with the same ease on Linux as on Windows, it might as well be Linux native, and non-FOSS Linux purist arguments are confusing and dilute that.
>> fall prey to the exclusive marketplaces on the rise
Valves initial support for linux was for precisely these reasons. Microsoft was talking about restricting which games could run on windows in much the same way an Apple does with iPhone software. The prospect of Microsoft having veto/censorship powers over violent video games struck fear across the industry. Valve then pushed towards "steam machines" running not-windows. Those issues have reduced as of late but were the trigger for what would eventually become the proton project.
It could also be true in a good way. Would it be so hard to claim that Linux users are more likely to report bugs, so the difference is not "Linux users are whiny" but "Windows users saw the same bugs and just suffered or stopped buying your program silently, while Linux users saw bugs and actually told you about it"?
This was circa 2013. Unity3D had barely included build options for Linux publishing, and it was a much less mature time for gaming on Linux.
So you're right, it isn't generally true today.
I personally don't use the Linux builds if the Windows version works with Proton, but I do download them for archival. I also don't submit bug reports to devs for Steamplay issues, so that's another factor.
Frankly I believe Proton is better for the longevity of these games on Linux. It's not uncommon for native Linux versions of games to break over time, or become a hassle to use as they rely on old unmaintained libraries.
Win32/Proton is almost like a framework game developers can target and not have to worry about OS specifics.
I own a valve index. I use it only on linux (mint) via proton. I can say that it does work. There are quirks. don't expect it to be seemless. For instance, more than half the time I start SteamVR but have to then "restart" the headset. Once it is working it is working.
Not all VR games support linux but many do, probably a higher proportion than amongst non-VR games. VR games tend to come from smaller developers who are generally not implementing the things that bork linux (eg DRM).
IMho now is not the time to get into VR, on any OS. You need a serious graphic card. Whatever you are running now, you will want something better once you plug in a VR headset. Good luck with that atm.
The restarting issue also occurs for me on Windows 10. Although, it usually occurs 80% of the time rather than half for me. I suspect it might be due to me plugging in power to the headset after starting the system, but I've seen it occur without doing that as well, so I am unsure.
I cannot speak to VR stuff specifically, I have heard of some issues with VR from lurking on other forums but I have no personal experience with them.
As for performance implications in my experience it tends to vary. Some games running on Proton run better than the GNU/Linux native ports and their Windows alternatives. Sometimes the native ports are better when compared to ones using Proton but for someone who is a "casual" I have not seen any noticeable performance difference. Of course this might not be the case if you are running on cutting edge hardware and playing the latest games.
There will tend to be at least a little performance difference from Windows, but personally haven't tested it. I have an Index and it works great [0], though I really need a GPU upgrade (which is impossible these days, as others here noted). I only play on Linux so can't compare to Windows, but besides some little things not being supported like passthrough camera, base station power management (though you can do it through your phone), it works without any fuss.
I've been using an HTC Vive on linux. It usually works pretty great. The performance might be percentage-points worse than a "clean" Windows install, but in my experience Windows didn't manage to stay clean.
I've got a gtx 1070, which at this point is pretty far from top-of-the-line VR-capable card. I'd probably get significantly better performance improvement per effort spent by upgrading my card than I would by tweaking the OS.
I can pretty consistently enjoy VR games. I haven't tried vr web browsing in a while; I remember it being pretty finicky on Windows several years ago.
My Valve Index works fine for me (both native and Proton), as long as I keep SteamVR on the linux_v1.14 branch. It does have some issues keeping up sometimes, but that's probably mostly my ancient GPU (AMD RX480).
The RX 480 is far from ancient and is probably one of the best cards that I've used. When I RMA'd my RX 5700XT (which still crashes after RMA), this thing was a champ. This card is still king for 1080p gaming and can handle 1440p too.
I can speak for Oculus Quest 2, plugged with a cable in the computer: it doesn't work at all. SteamVR works by itself in native linux mode, but for the Quest 2 to be recognized, you need to run an Oculus windows only application that makes it look like it is a Rift headset... So... after years on Xubuntu only, I ended up reinstalling Windows to satisfy my new VR gaming "needs"...
There is still no functional VR media player for linux, none of the Windows ones work with Proton and the official SteamVR Media Player has no linux release.
Not sure what you mean, but there is the open source vr-video-player [0] that works with YouTube, can put flat games on a virtual big screen, etc. Works great.
I found it in a round about way too, could use some better publicity maybe. You can also use this to enable side-by-side 3D in VR, so like the old Nvidia 3D shutter glasses that made games pop out of a flat screen, you can see that in your virtual screen in VR. Take a look at SteamTinkerLaunch [0] to set that up (currently helping organize that giant readme, but the info is all there to play around with [1]).
Edit: I should say side-by-side mode works for games with it builtin (like Trine) but can also use shader injection to emulate this which can work pretty well too.
Just to make sure we're talking about the same fix, do you mean running the LAV installer first (edit: followed by selecting DirectShow in the options)? That worked for me with Proton 5.13-6.
Welp I got curious whether I'd missed a step so I gave it a once over, took me 7 hours to get it working. Turns out Proton does not like to run from an NTFS partition so I reinstalled steam on ext4. Now it runs but I couldn't get Direct Show to work, only the VLC video-path. I assume the LAV installer failed somehow. I also had to mount bind my external drive in my home folder otherwise it wouldn't see it. And I also had to reset whirligig's settings manually in the prefix folder (steamapps/compatdata/451650/pfx/drive_c/users/steamuser/Application Data/Whirligig/production) because it randomly stops accepting inputs.
Just writing it all out in case somehow comes across it.
I finally took the plunge and started dual booting with Fedora as the default. Unless I plan to game I just use Linux and it's been awesome. Though I can't use Wayland (Nvidia) and digital audio is flakey (though fixed in fedora 34), none have been deal breakers.
Proton is neat for sure, but unfortunately modern anti-cheat solutions expect Windows and will not allow Linux clients to connect. There's also a few games that I expected to work but simply won't launch for me, like Elder Scrolls Online.
I'm a fan of the Linux desktop, but for me the easiest solution is to have a dedicated Linux PC (right now an XPS 13 Developer) and a Windows machine for playing video games. I don't have the patience to troubleshoot getting games to run or perform well anymore.
No kidding. After spending so much effort on verifying that the code I'm running comes from trusted sources and that I have a decently secure system, I can't help but feel dirty after allowing some sort of weird DRM/anti-cheat service that needs to phone home just so I'm able to play a game I loved from 5 or 6 years ago.
Riot's Valorant rootkit is active from boot and actively monitors everything you run and will block things it doesn't like or doesn't recognize.
Most of the other kernel anticheat rootkits are more polite and don't run until a game starts them, at least.
In general having a bunch of random stuff from video games running with kernel permissions is spooky. You never know whether someone will find an exploit in one of them, or if it will cause performance, stability or data integrity problems.
> Riot's Valorant rootkit is active from boot and actively monitors everything you run and will block things it doesn't like or doesn't recognize.
Honestly, if I was responsible for building an anti-cheat system this is the way I'd go about it. Anything that can run that you don't know about (e.g. because it ran before you started) is a potential risk.
Userland can run DoS attacks, it can mine crypto, it can run keyloggers, it can steal, encrypt, and delete your files, it can make your system not properly startup, it can replace sudo or other programs that ask for passwords with a custom version, it can steal whatever's on your clipboard, it can infect other operating systems (depends how they are mounted), and much more.
Modern "anti-cheat" solutions are invasive rootkits. I have no interest in running that on my computer for that purpose. I wish they'd invest more in server side AI instead to handle this, but it's much easier for them to simply put more malware on the client side.
Some developers aren't even denying that it's nasty, but excuse it with "no one cares anyway" or "we already could snoop on you, so don't complain if we make it even worse" which is disgusting.
Cheats themselves are basically rootkits, and you can't beat a rootkit when you are running on top of it. Anti-cheat pretty much has to be like this.
Server side enforcement is not only heavy, but has much of the same problems as the client side. It's running on a layer even higher than the client side anti-cheat. How can you tell if someone is running an aimbot or just has good aim? Sure if they do something outright impossible you could ban them, but heuristic approaches are going to have problems with false positives as well as false negatives.
Server side doesn't violate user's system with rootkits. How to detect things with good level of correctness using server side AI is a good question. But it's a much better problem to solve than how to add even more privacy invasive malware on the user's system.
> How can you tell if someone is running an aimbot or just has good aim?
That's the point. I don't care. As long as the game is enjoyable. And I'm sure AI can be gradually trained to detect cheating in more sophisticated manner do differentiate non human from human patterns. Not a trivial issue, but something they should invest money in as above, instead of rootkits.
14:22:01 *Shmerl has joined the game
14:22:02 [DefinitelyNotAnAimbot] headshots Shmerl
14:22:05 [AnotherTotallyHumanPlayer] headshots Shmerl
14:22:07 [DefinitelyNotAnAimbot] headshots Shmerl
14:22:07 DefinitelyNotAnAimbot is on a killing spree!
14:22:10 *Shmerl has left the server
I already explained the idea above. Trade off of the server side AI detection is way better than client side rootkit idea. Neither is perfect, but the latter is outright disgusting and crooked.
not sure why you are downvoted. You speak the truth, and as usual get downvoted without a reply.
multiplayer game have the choices: a) ship game with malware/trojan to try to prevent cheats, or b) open up for cheats (even if client side only, like see trhu walls)
Most popular games chose option A (and still fail preventing both client side and remote hacks)
Or the server could hide the data from the client that the client shouldn't be able to act on until just before that data would be seen by the client. (obviously with a slight tolerance for sending a bit extra that clients might need if lag rubber-banding predicts it might be revealed)
Another option is to develop server side AI that can detect some non human behavior or behavior patterns that are cheats. It's not full protection but for sure more appropriate than putting rootkits on the client side.
here is another idea: proper ranking of player abilities! crazy right? something so simple should be a day-one feature right? that would put all the hackers together and they could even compete in their own hacking league... 100% of clients satisfied!
now think about game companies failing to put that single feature to work correctly, what changes do you think a AI that detect human behaviour have or working well in that space? :(
My complaint is similar. There are a couple of games that I really wish I could play using proton. However, while I used to dual boot, now I don't even do that and I simply forego playing those games.
I have too many games in my library to worry about not being able to play a couple more, I guess. But, if I could, then I would. So I just stick with whatever can run with proton.
> Proton is neat for sure, but unfortunately modern anti-cheat solutions expect Windows and will not allow Linux clients to connect.
Keep in mind that many people are interested in single player or local multiplayer that do not require anti-cheat solutions. They will hardly ever run into problems on that front.
I suspect the largest problem with Proton is that support will be biased towards recent popular titles based upon common game engines. Replicating all of Windows is not practical, Valve themselves will be most keen on supporting games they can generate revenue from, and community contributions will come from people who have an interest in getting particular titles working as well as the technical skills to contribute.
Proton is in the works to support anti-cheat. Vital kernel support was recently merged. I don't know the details, only that it is a goal of proton and hopefully will work. Many games use the same anti-cheat so if everyone cooperates it could work out.
I give it 0% chance that Proton will support anti cheat. How does an anti cheat checking "fake" windows kernel structures in linux actually accomplish any anti cheat?
My solution for the anti-cheat problem is NVIDIA Geforce Now (via Chromium). Sure you will need a good internet connection, but at least you can simply start it right from your desktop without much hassle.
My problem with Proton is that they are not strict enough with their ratings. I see a game has "platinum" or "gold" support and think "great, this will work well!" but then I discover it crashes after alt-tab and multiplayer doesn't work at all, which I consider critical bugs.
To me, the levels should be:
* Paltinum - the game works as well as it does on officially supported platforms
* Gold - the game works almost as well as on supported platforms but with minor niggles that don't significantly affect the experience
* Bronze - the game works in some form, but major things might be broken. It would not ship in this state on official platforms.
However, the project is a great start and I look forward to what they do next!
To be fair those grades come from ProtonDB[1] which is not affiliated with Valve or Proton. Though I agree that having a clear rating system as to what to expect in Steam would be great.
I agree, but the ratings are self-selected by the reviewers so it's hard to enforce. The more the reviewer is comfortable in the linux/steam/proton ecosystem, the more inflated the ratings get. I'm guilty of this myself, rating a game platinum because it runs great perfect except for multiplayer (which I don't want) and only if you give it this esoteric launch command (which I had to do once and promptly forgot about). If I'm lucky I remember to add those caveats and what the esoteric launch command was. I'm usually just so happy that I can run the game now after decades of a terrible linux gaming experience that I can't help but over-inflate the ratings.
There is also a huge range of hardware/software.
Different kernels, drivers, AMD vs Nvidia, Wayland vs XOrg.
A lot more Linux users are moving to AMD GPU, so when I see platinum, I assume at least great support on AMD.
Proton is a very impressive project and works with many titles that I've tried. For anyone not well acquainted with it and wanting to try games not part of Steams official compatibility list, look at https://www.protondb.com/, think of it as similar to Wine DB. For unsupported games, I usually use GloriousEggroll's custom build: https://github.com/GloriousEggroll/proton-ge-custom. This "fixes" many games, especially if they use videos in cutscenes and many other things.
There are some features that I was never able to get working correctly, e.g. remote Steam Play with Streets of Rage 4 where my friends stream would not load up or controllers would not map, but for single player gaming, this would not be an issue.
Performance is (to be expected) less than Windows and games can exhibit graphical artifacts or crashes but it is not bad enough really complain about given how amazing it is that this exists in the first place. I will often put up with these (imo) minor defects than boot to my Windows install. Steam cloud sync even works correctly for keeping your save data between OS'!
One thing to be aware of that I don't see people mention (maybe because it's a niche setup and game dependent), is that using fractional scaling can completely mess up some games display, I believe due to how fractional scaling uses a framebuffer larger than your real resolution. Make sure to set your scaling to 100% before launching games which have this behaviour, e.g. Tekken 7.
I've experienced similar in Windows, where the remote controller does show up but both players become Player 1. However, the stream itself always works and doesn't with proton, although it's been months since I've tried.
True though, this functionality could do with fixing on the Windows side before we can expect it to work via proton.
The problem with Proton is it is leading many game developers to actually drop Linux support. They basically say players seem to be able to get the game to work on Proton and that's that.
But with no official support there is no guarantee it will continue to work with updates. There is no promise to even try to make it work if it breaks. And that's the major stuff. Imagine spending 20, 30, or 60 dollars on a game that can break at any moment and know there will be zero support waiting for you. And that's hard breaks. Performance hiccups will be given zero attention by the developers.
There is all this talk that Proton will make people want to develop native Linux ports but I don't see any data or logic to back that up.
I have a game on Steam, developed primarily on Linux, and providing a Linux build (in addition to Windows and Mac).
Linux makes up approximately 0.5% of my sales. (Mac is about 2%, and Windows is the other ~97%) And from conversations with other developers, these are pretty standard percentages. I make and offer a native Linux build because I wanted to do it, but the financials really aren’t there to justify it from a hard business perspective.
Proton really isn’t the thing that makes game developers choose not to make and support Linux builds of their games; it’s the lack of an audience (and often developers not knowing enough Linux to be able to provide support for it). My hope is that Proton can build up the audience, so that it starts making more financial sense for studios to serve that audience.
Exactly... I keep reading these concerns that Proton will cause developers to ignore Linux, when really there's effectively zero incentive for developers to pay attention to Linux in the first place, given how few people use the platform to play games.
In my view any system that makes it realistic for people who buy games to use Linux full time can only increase the chances a developer will be able to justify supporting a Linux version of their game.
I use desktop Linux primarily (complemented by a Windows partition and a Mac laptop) and would love to see more support from game developers, but the idea of such a small niche of users turning their noses up at "ports" and demanding native builds with support is borderline absurd.
Basic question, if someone buys a game to run it through Proton do they look like a Windows or Linux user on your end?
How would you feel about games being made available for free to Linux users if it uses Proton. If the game contributes basically nothing to your bottom line and you don't plan to support them anyways, why not? It will only grow the audience more quickly.
Users running a game in proton show up as Linux users, not windows users. Because of this, many games already show a bunch of Linux players even though the game doesn't have a native port.
Couldn't Windows users boot into Linux then to get games for free? Like, it would probably increase the share of Linux users but Windows users would decrease. And when you start charging for the Linux port, a large amount of those users would flock back to Windows.
dual booting is a kinda a lot of work just for some free games.
You also could charge a dollar since you are often offering a strictly worse product for Linux users. That's what happens in many other markets when you are trying to expand a userbase.
There is clearly a dollar value to providing support. Why shouldn't the price reflect that?
At least on Windows you can try troubleshooting and various workarounds to problems to a certain extent, or ask for a refund.
I bought Pillars of Eternity on the Nintendo Switch for $60, which was broken on day 1, still broken today, and officially abandoned by the publisher (Versus Evil)
This isn't related to the OP in any way, I'm just still angry about it.
Linux players, in my experience, are more used to having their problems be ignored and have stronger feelings that they are part of a community and thus are more forthcoming with potential fixes and/or testing of things for other users that are also running linux, so they too help with troubleshooting and workarounds. I feel your pain about the situation you ran into with the Switch.
> There is all this talk that Proton will make people want to develop native Linux ports but I don't see any data or logic to back that up.
I haven't heard of this, honestly. I'd fully expect it to damper Linux port development, and I'm not sure that's a bad thing.
It's entirely possible for a game developer to treat bug reports from Proton users as legitimate, just as much as they may for a native Linux port. Wine is effectively just another Win32 runtime that happens to run on the Linux kernel instead of WinNT.
I've had instances where the native Linux port of a game failed to launch entirely, but the Windows version through Proton worked flawlessly. I've also heard that some games perform better on Proton than native, because of the DirectX -> Vulkan translator outperforming straight OpenGL on Mesa.
Other commenters have mentioned this, but it boils down to market share. Linux's market share is downright trivial. If I was a game dev being raked over the coals for a release date, I wouldn't frankly give a damn over Linux, and I say this as someone who mainly uses Linux.
That's why I don't think this is a problem. If Proton becomes big enough then it becomes another "target", just another runtime to replace the old glibc/mesa one that devs can test if they want to.
Linux will always be a second-class citizen to game devs until it gets a lot more users.
But the new people that come in, those that likely migrated from Windows or Mac, are not going to care whether or not the game is a native Linux port or if its running on Proton. They'll only care that the game works, and works well.
If we ever get to the point where Linux gamers become a significant percentage of the market, then developers will be forced to pay attention to Linux support. If Proton can't deliver competitive performance and stability, then that means they will be forced to do proper Linux ports.
So the only thing needed to encourage developers to provide real Linux ports is to increase the size of the Linux gaming community by any means necessary. Whether that's through Proton, or even virtualization, the goal stays the same.
I think it's absolutely fine. How many people test their web applications on Linux? Few, because there's a virtualization layer between the application and the underlying operating system, so webapps are a write once, run anywhere application.
Games can be the same, they just need an abstraction layer - be it a VM, an emulator, or whatever Proton is.
And sure, you may not get perfect performance, but that is becoming less and less of a problem.
also from several game devs I've talked to, not only is the market share negligible, the bug reports aren't. Common sentiment was that Linux was ~1% of their sales but a third of complaints.
I know this sounds silly, but would you be able to confirm that this is based on actual conversations that you've personally had with game developers about projects they've personally worked on?
There have been rumours stoked especially by tweets from the Planetary Annihilation developer that he has since retracted/clarified but these still seem to fuel a lot of negative perceptions of Linux support that aren't seen in the main.
That's fair. I know it's more likely that this is the case on HN, but there's been multiple times on Reddit when I've asked people to elaborate and it turns out that when they say "I've spoken to Devs" they actually mean "I read a comment on Reddit" or "I saw a tweet that said it".
This probably reflects the character of Linux users more than Linux. To really unpack that you need to properly categorize the complaints: (Linux platform bug, Cross-platform bug, User error.) If 50% of the bugs are real cross-platform issues, then ditching Linux saves a lot less than you think (and you're potentially losing some high-quality free QA.)
This. Most of the Windows users in my circles wouldn't even think of writing bug reports, whereas many Linux users are developers, often immediately think of writing a bug report, and are also technical enough to do it[1].
[1] It takes some technical experience to make an educated guess of where the problem lies. Drivers? OS? Game? Hardware? And if you're on Windows: Some gaming overlay? AV?
Have a demo so users can tell how well supported their platform is.
Be clear about the target platform (E.G. Tested on Debian 10.8 + NonFree, Ubuntu 2020.04 etc; also include the minimum supported OpenGL / Vulcan / whatever version etc.)
Document the product execution lifecycle, and how to manually skip steps. (E.G. steam calls X to start the launcher, the launcher calls Y to start the game. These are the arguments each take to modify behavior.)
Have developer level debug checks in the logs. Print to standard error where you're trying to open a log file ("Opening log file: %s\n"), have an example of what a healthy log file should look like. If a native command is missing say so, and if there's a test-platform link to the package page for that platform, as well as the source website. (Eventually historical gamers might need to visit Archive.org to grab the last published version.) Have debug levels to increase verbosity (even if it's just "production" vs "collect crash report") validate every assumption and requirement in the crash report log level. You shouldn't need to ask the user for any additional information other than the log file, because it should all be right there in the log file.
> Imagine spending 20, 30, or 60 dollars on a game that can break at any moment and know there will be zero support waiting for you.
So spending < than people make in an hour here for a potential inconvenience that comes from updating to a new release - I can hardly imagine it.
Multiplayer games that need to be up-to-date and competitive games would probably be annoying to hardcore gamers - but frankly if you're into that you'll be sensitive to performance as well and you should just get on a supported platform.
I am sensitive to performance, but part of that is being able to alt-tab over to my Linux desktop rather than having to switch machines to do things other than play this one Windows exclusive. Actually the main part is that. "Gaming device" is a secondary function of my computer.
Meh, the author is making it sound like Proton will deter native linux ports. Reality is there would never be native Linux ports and you should be thrilled Proton/WINE/whatever gives you any options at all. The market isn't there - I see Valve linux efforts as a hedge against Windows screwing them over.
There were Linux ports before Proton and I'm making the case that Proton does not create the right incentives to grow a market for Linux games.
Like imagine a restaurant that served food to people in suits and people in tshirts but the people in tshirts tended to get food poisoning significantly more often. Would you consider the response to this concern "If you don't want food poisoning maybe wear a suit next time" a reasonable response?
I say whatever. I think it makes no difference that a game supports Linux directly, or via proton. Either way you get a tested product, and neither of them is more friendly to the spirit of free software. Or, if I could have a preference, I'd go with proton based solutions - because over time, that makes proton better, which means even more Linux compatible software.
> There is all this talk that Proton will make people want to develop native Linux ports but I don't see any data or logic to back that up.
Never heard this and I agree it doesn't make any sense (the opposite is likely to be true actually).
Wine exists because people wanted to run windows software, Proton exists because Valve wanted to compete with Windows and mainstream consoles and needed to run most Windows games to do that.
That's it.
TBH, I think they were successful, ProtonDB is good enough and I can game on Linux pretty well and I could definitely game on a hypothetical Steam console, especially if it were open.
Maybe I will, once I settle down and buy a dedicated gaming rig / have more time to play.
Could you cite some examples? I know of games that have dropped Linux support (RUST, Rocket League) but those are all to do with Anti-cheat rather than citing Proton as a feasible alternative to a native port.
Supergiant has previously released all their games (Bastion, Transistor, Pyre) with Linux support. With Hades they explicitly said would not come to Linux, and in fact cite the presence of Proton as a reason [1]
Nicalis games has released games like Cave Story, VVVVVV and Binding of Isaac with Linux support. But the latest DLC of BoI will not have Linux support.
Is it a bad thing that Hades doesn't have an official Linux client if it runs perfectly under Proton? They seem to be willing to invest heavily to get the game onto more platforms considering that (AFAIK) they rewrote the entire game in C++ to be able to port it to Switch, so it would surprise me if this is a "we don't care about you" situation and not a "Proton is good enough and doing a from-scratch Linux port would be expensive" situation. For their games before Hades they were using a portable middleware layer (FNA or MonoGame) and the C++-based engine they licensed for Hades is not the same.
I definitely do not believe that Supergiant's choice here was motivated in any way by Proton. I think the costs simply didn't justify a custom port for them this time if making it a better experience would be difficult.
P.S. Hades has an official Vulkan client, not just Direct3D, so the gap between native and emulated on Proton is much smaller than it would be for many games.
Thanks, I will read up on these. I was feeling fairly secure that this was a concern that hadn't materialised, but it seems I have since been proved wrong :)
Thanks! And believe me I want to be proved wrong on this. If you find any developers that were motivated to create a native Linux port of their game due to strong numbers on Proton I want to know!
It's a bit of a shame that Valve pretty much abandoned their Steam OS/Steam Machine endeavor, even if focusing on just one component (Proton) is arguably better than just having to deal with an entire distribution.
That said, I'm routinely amazed at how good Proton has gotten at running Windows games. I've still got dual boot for some stubborn stragglers, but the vast majority of my library runs just fine on Linux.
SteamOS, Steam Machines, and Steam Link all occurred at about the same time and they were definitely a response to the perceived threat of Microsoft locking Windows down to only Windows Store applications.
Good news is that didn't happen and Valve continued to improve gaming on Linux for everyone for free anyways.
I would not count steam machines out just yet. I wouldn't be surprised if the number one complaint about Steam Machines/OS was the limited library of games. Maybe they decided to just take some time and focus on Proton and then consider reviving the Steam Machines.
Yup. Valve is putting serious effort into Proton and there are a number of reasons I can think of including Valve loves Linux, Valve thinks that the Linux market is/can be profitable, Valve wants to keep its non-Windows options available if only to threaten Microsoft. However a next generation of Steam machines definitely seems like it would be present on that list.
I think a streaming service with a Linux backend is more likely than another Steam machine push.
One of the biggest problems with Stadia and the like is that you have to buy another copy of the game whereas Steam already knows what you own and will let you play it locally.
Strictly speaking, Stadia is "a streaming service with a Linux backend", but I think Steam could do it better than how Google's gone about it. The issue would be that Valve would need to renegotiate it's distribution deals to include streaming rights in addition to providing user downloads, and many publishers would drag their feet on allowing that, based on how publishers made noise and opted out of nVidia's Windows-based offering.
But a service that offers my Steam library via cloud streaming would be a very tempting offering.
Interesting. I wonder if Valve is building this so third parties can do the capital-intensive work of building up/out hardware (given that they're listing GeForce NOW as the only supported client), or if they're also intending to enter the market themselves.
SteamOS development was only contracted-out by Valve and while many like the notion of it, SteamOS is barely different than building a Linux machine and setting Big Picture Mode to execute on startup.
Really? I thought it was developed in-house. From what I understand much of their company was focused around Linux at the time (Steam, SteamOS, Hardware, Source engine port, L4D2, etc...).
I'm sure they also have/had contractors working on it like they do for the other Linux gaming effors but a claim that it was "was only contracted-out by Valve" needs something to back it up.
I found that though not everything runs under Proton, there are enough games that do that I can allow Proton to be my filter of what I play and don't. There are too many games that I want to play but just don't have the time to that Proton let me naturally narrow that list. I may miss out on something I REALLY want to play, but it's okay. There are just too many good games.
There are so many worlds to experience, but they all take so much time. These artists create such incredible places it makes me sad I don't get to experience them all and never will.
Sadly what seems to happen to me is that I find one I like and just spend an absurd amount of time in it. RDR2 for instance, I spent maybe 30 hours not actually playing the game - just wandering around enjoying the scenery.
EAC (Easy Anti-Cheat) is the main reason why I've not switched from Windows to a full-time Linux desktop. While EAC does include support for Linux[1], it's up to the developer/publisher to enable it.
Considering the complete lack of attention TF2 gets from valve I wouldn't consider it a fair reflection of VAC's effectiveness. It had been infested for ages before a media outcry about the bigoted chat spam finally spurred valve into action, yet all they did was ban f2p accounts from using chat.
I don't play CS that much but afaik aimbots are there as well. I know that it has manual reports/user review systems so I imagine VAC is not effective as an automated tool
Counter-Strike has a bunch of anti-cheat systems, but they solve different problems (VAC, Overwatch, Prime Matchmaking, and VACNet). These systems all work together and I'd say it's pretty effective. TF2 could do with the same.
But my original point is that you don't need Kernel based spyware to do anti-cheat.
Still never heard of it beyond this reference, but I assume it's a part of some popular games? (Scroll down on page above to see.) They list Fortnite but I thought that used something with a different name. Battleye? Do these games use multiple anti-cheats?!
Making wine compatible with EAC is very different than making an EAC bypass. The end goal is for EAC to be able to do the same checks as it could as when running on Windows.
I really think we need to get out of the habit of calling game developers 'Lazy', especially for an industry that is famous, notorious even, for overwork and crunching.
I think it would be fairer to say that it doesn't get prioritised, especially over anti-features such as microtransactions, DRM or things of that ilk. Calling them lazy is disrespectful, hurtful and betrays a lack of understanding of the development process and the industry at large.
It doesn't help that game dev (IMO) is literally the most difficult software development possible:
- massive front-end visual dev, both static and animation, that often require logistics and endless fiddling to get it just right
- hefty back-end dev, especially when dealing with massive latency questions (e.g., MMOs) and calculations (e.g., 4X strat)
- audio design that must sync with graphical elements
- on top of all that, higher standards for input syncing to video output than almost any other type of app
...and then overworked and crunch-time to top it all. I'm amazed that we're even getting finished games these days now that devs can sell a near-playable v0.6 as "Early Access"!
To not enable a feature that EAC explicitly provides and would allow people to use a product, and that requires almost no additional work (since it's not linux support in general, just EAC linux support), I consider to be lazy. Although, it's probably a mgmt decision, not a dev decision.
I understand linux support takes time and it usually isn't worth it. But this is just flipping a switch from what I've heard.
I think flipping the flag is likely not the only amount of work. Support will at the very least involve customer support, legal, marketing, sales etc. Dev effort to enable is likely not a factor in their reasoning to not support the platform.
Even then, I would be reluctant to call it institutional laziness. Businesses strive for efficiency. Can not doing a high cost thing be called laziness? Sure, but I think it's still disingenuous and misrepresents the issue.
Proton is really awesome. It was usually possible to get Wine working somehow, but Proton really nailed the usability side and fixed a few stubs in the process. Truly a leap for Linux gaming.
This. Getting games working under Wine more often than not involved a research project where you figured out what exact version of Wine and what hacks you needed to make something run. Proton is basically just Valve doing all of the homework for you, which is awesome.
For anyone looking for a basic set of steps to migrate away from Windows via dual-booting, the following is working flawlessly:
1. Partition HDD, create Pop_OS live Linux usb (or desired Linux distribution, just remember to include Nvidia/AMD graphics driver).
2. Install OS, with separate /boot partition than Windows.
3. Return to Windows (can do this as step 1 actually) and install rEFInd boot loader on Windows EFI partition and replace bootx64.efi or whichever default boot file for your BIOS with rEFInd.efi.
REFInd should automatically locate both installs next time you boot.
DISCLAIMER: Do this to access your game saves. Steam will not download missing compatibility but instead reinstall your games. Be sure to grab the saves beforehand.
Follow up, decided to tackle it on my lunch break. I had issues but the tutorial worked. All that tutorial does is help you mount NTFS on your Linux OS on startup automatically. Once you do that you're good to go.
The misnomer is adding the second library. The steam UI only lets you change the folder in the currently existing libraries (Settings -> Downloads -> Steam Library Folders is wrong). Instead try to install a game that you know is on that drive. When the game install prompt pulls up, for game install location select the dropdown and "Add new steam library", pull up your file explorer and set it to the `Steam` folder on your ntfs drive. After that it will search for common files for that game and install anything missing. It will also remove anything Windows specific. The process will also identify the rest of the games on the drive but will prompt for install when you try to play. I hope that helps!
Obviously your Proton matching mileage may vary per game!
That's a different problem, all together unfortunately. I think it is possible but I have not yet migrated that far. I am still in the "choosing a distro" stage (I'm enjoying Pop_OS so far but we'll see). I have read in some comments elsewhere that Steam will download the correct binaries if you can point to the library.
Your link is missing a `/` between `Proton` and `wiki` btw.
I game very little, mostly because I don't wanna spend more of my free time in front of screens (since my work and several of my hobbies involve screens). But in the last year or so I've picked up some casual relaxing games.
Starting out, I remembered the situation of 15 years ago, fighting with Wine etc. I just assumed that I was lucky and all the Steam games I picked up recently had native Linux versions. Little did I know that several of them were running through Proton, and the experience was so perfect and seamless that I didn't even notice. Impressive!
I installed it recently on a newly built pc specifically for gaming. I'm quite shocked at how good it works! The only thing holding me back from switching completely is there's some nonsense getting the xbox controller to bind to the pc vis bluetooth. If I can get that resolved I don't think there's anything else holding me back. What an amazing accomplishment!
It's not the same thing, but personally I find the Xbox controllers are better when used with the official USB wireless adapter and xow: https://github.com/medusalix/xow
Firstly, you need an official wireless adapter, bluetooth is much slower and also trigger buttons won't work. Even with the adapter, the pairing might be awful, but there is a little known fact that you need to plug in the controller via usb for a moment, unplug, and it will just work (for the same machine). Also install x360ce for older games.
With these in place, the controllers work 100% great for any controller game.
I didn't realize there was a USB adapter. There's a problem on Windows where pairing an xbox controller via bluetooth can result in reduced performance, so I've taken to using my switch pro controller in Steam. The switch controller doesn't work for games that can't be launched via Steam, though, so maybe I'll pick the adapter up (and someday move to Linux maybe? I keep thinking about it).
I don't think it's worth buying anything else for a PC other than an XBox controller. They are the best price/performance, and have the widest support. Anything else is gambling wether it works.
But if you already have a Switch Pro, you can try x360ce - it can map the buttons to standard Xbox bindings.
Yep, I already had a Switch pro controller lying around. The nice thing about Steam is that it works pretty much 100% of the time for anything launched via Steam (exception: it doesn't work for Xbox game pass games added to and launched via Steam). Added bonus, it has gyro, so I can kinda sorta play Doom less badly. I'll take a look at x360ce, thanks!
I went a decade without playing any video games. For me, doing so eliminated the need for a Windows PC. I was able to focus on learning new skills and grow professionally without the distraction of games. Hearing from friends about games built up my curiosity, and so I picked up Skyrim in 2019 and Fallout 4 in 2020, both via Proton. With a couple minor bugs, they work great. I am so glad to be able to game on Linux.
I'm not really sure what went wrong on my Xubuntu 20.04 system; I was never able to get a single game running under Proton. Attempting to do so would essentially soft-lock the entire Steam platform until I killed every process related to Steam, pressure-vessel, and Proton.
In the end, I ended up reinstalling Windows because of some other system-related issues, but I'd have loved to be one of the happy Proton users playing Windows games on Linux.
While it is definitely not streamlined and very expensive, I've had a wonderful experience running a Windows VM and passing one of my GPUs through to it.
Even VR works flawlessly, which is otherwise unusable on a linux desktop.
Proton definitely still has major issues. A lot of the well-rated games on protondb are barely playable. Still, I've played a lot of games using it I otherwise wouldn't be able to experience.
>running a Windows VM and passing one of my GPUs through to it
This is very inconvenient because you have to install a new a GPU and then plug in antother monitor into th at new GPU.
>which is otherwise unusable
VR works nearly perfect for me. The main drawbacks is a broken video player in VRChat, no voice recognition in games that use Window's speech API, some anticheats not working, and that NVIDIA still hasn't added driver support needed for async reprojection. One final thing is that audio devices sometimes needed to be configured to the right device the first time you run some games, but from what I've heard from Windows users they have their own share of wrong speaker or microphone problems.
Hearing that VR works well with passthrough makes me want to try it again. I remember when I last tried it, everything worked great except for sound, which was staticky and choppy unless I handed the whole soundcard over to the VM.
Some setup is required, but KVM passing the system audio to pipewire-pulse worked first try for me actually. I'm normally using a virtual desktop to stream everything to my Oculus Quest 2, including audio, and it works surprisingly well.
How is Proton a technology/library/sorftware? I got the impression it's just a preconfigured Wine, but not an actual implementation. Sorry if I'm misinformed.
And _if_ that's true, I'm sad about the credits not going to the Wine team.
The 'secret sauce' is actually 'Steam Play' which is the automated wrapping, configuration and execution of Proton wrapped games without the user having to do anything (other than a confirmation box to confirm that a compatibility layer is being used).
The Steam Play component turns it from a 'nice meta-distribution for wine' into 'killer quality of life improvement'.
I guess it somehow makes sense for Valve to keep the per-game tweaks private. With all of that money they're printing though, I sure wish they could feel that they could afford to be less defensive.
None of it is private. The per-game settings are all listed here, the options are all implemented in Proton, which is completely open source: https://steamdb.info/app/891390/info/
Proton, Linux gaming etc. do not work well unless you are running open source graphics drivers (... NVIDIA) and standard resolution 1920x1080. Try any of this with NVIDIA and display scaling other than 100% and you are going to have a bad time.
I run at 3840x1080 using the closed source nVidia drivers and it generally works fine. I don't have any scaling going on though, and I can definitely see where that could be an issue.
I can't say that I recommend the nouveau drivers for gaming.
Proton is what let me change my PC from Windows to Linux mostly full time. Now I only have a handful of reasons that I need to boot into Windows to get things done and out of 1000+ games on Steam, very few that I just can't play in Linux.
I'm sure I'm not the only one who noticed the trend from that graph. We seem to be floating steady at ~50% now.
I don't mean to be cynical, but what do you think would bump the current trend into overdrive? My only estimation would be to make gamers actually want Linux over Win10, and my limited experience tells me that the word still scares normal gamers.
Valve recently updated Remote Play so that hosts can send anyone a link to install the Steam Link app (available on every major platform but macOS at the moment) and join local multiplayer games remotely. Guests don’t even need a Steam account. Great quarantine feature for games that don’t require very low latency! And it’s fully functional on Linux.
I don't understand the comments saying it's disincentivising developers from developing for linux. They would never do it otherwise. Proton is great and since PopOS is here I'm finally able to switch to linux completely and am super happy about it. Things will only get better from here
I am incredibly grateful for proton -- it mostly just works. However, configuring it without steam itself is a bit of a pain.
Is there a good UI to get it to work with gog.com games? I don't really want to buy on Steam because of DRM worries, but I do throw them a bone periodically entirely because of proton.
> DX12 support in certain titles (although this is getting better as VKDX12 improves continuously)
I googled "VXDX12" and this blog post is all that came up in the search engine. Is that Vulcan or something? (sorry I know little about game development).
Wine / Proton are great for Linux gaming, no doubt. It's a nice workaround for big publishers completely ignoring Linux gamers. It works very well and bypasses these market politics shenanigans making many games playable on Linux.
There's no way to run EAC in Linux without actually actively trying to deceive it. EAC is trying to look deeply into the windows kernel to find oddities.
>Did none of those 7000 games work on Wine already?
Not on Steam, and not without user time investment.
Steam Play (which uses Proton) allows the Steam client to only show games that are known to run well on Linux, automatically installs and configures a Wine prefix for them and then launches them _as if they were native Linux games_. No mess, no fuss. If I were to put Linux with Steam Play enabled in from of a Windows layman, they would likely not even realise they were playing games that weren't built for the platform. It 'just works'.
I would agree if the article was saying "7000 games enabled in Steam", but it's not:
> we are very close to 7000 Windows games confirmed to be working out of the box with Proton on Linux.
A better point of comparison for the actual claim would be Wine-launcher or CrossOver or some other Wine wrapper. As it is, the base for comparison used is "nothing worked before"
Given that this news provider reports quite frequently on Proton, I can understand that they assumed their readership would know what they meant. I will concede that the wording is pretty loose objectively.
Hi Jamdrese,
Need one urgent help for memtest
Can you please share your code. I want to test it on my system?
I got your reference from below;
jandrese on Dec 1, 2014 | parent | favorite | on: Memcpy vs. memmove
It's fun to benchmark memmove and memcpy on a box to see if memcpy has more optimizations or not. On Linux x86_64 gcc memcpy is usually twice as fast when you're not bound by cache misses, while both are roughly the same on FreeBSD x86_64 gcc.
Linux (2.4Ghz Xeon X3430):
I would have to assume that OP is lamenting the fact that the games themselves are not running natively on open source, and the existence of Proton detracts from game developers / publishers targeting Linux/OSS because now they don't really have a need to.
Or he could be lamenting that the games themselves are not open source, but I haven't heard many of even the most die hard OSS evangelists suggest that AAA gaming content should be open sourced.
The games I mean. I guess I'm in the wrong topic here, but if you play those games, you implicitly have to trust their secret code on your network. User account and all. Obviously most here have done that a long time ago and don't even give it a second thought. This is normal in these times of Windows and Facebooks, but I still care.
I believe Valve is working on Flatpak sandboxing for games. If this happen that would be one more reason to game on Linux instead of Windows.
It's not as good as open source but let's be real, you'll never get AAA open source games.
Games don't need to access personal data (such as contact, phone number, photos, files, private messages, etc.) so with strong sandboxing I guess it could be a okay solution privacy-wise
I already run Steam in Docker for this reason, with its own home directory mounted as a subdirectory of my real one. Even before games swiping my homedir I was worried about Steam wiping my homedir, as it's already done once in the past. [1]
Though ironically that means I can't use the new Proton runtime thing ("Soldier runtime" I think?) that sandboxes games via user namespaces, because my distro doesn't build the kernel with userns support so it would require me to give the Docker container more privileges.
> It's not as good as open source but let's be real, you'll never get AAA open source games.
Free software philosophy (the "F" in "FOSS") allows the art and data files (levels) of a game to be proprietary, while keeping the code open-source. Sell the game itself, code comes for free.
There never was a time when the majority of games were open source, all the way back to 8-bit home computers. This was long before Windows, Facebook or an open source UNIX flavour even existed.
My only complaints are that steam uses arbitrary numbers instead of human readable labels for emulated AppData folders. It can be time consuming to locate a save game file. Also Streaming cross platform isn't a pleasant experience yet but it's getting better and I really appreciate the feature. My final gripe is that when adding media to a Steam chat on Linux the file open dialog does not cache the last folder you visited and doesn't support multiple files. This compounds the first problem I listed making it EXTREMELY time consuming to share multiple game files with friends quickly.