Valve's Proton Has Enabled 7000 Windows Games on Linux
boilingsteam.com
boilingsteam.com
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.
https://store.steampowered.com/app/573100/Battlefleet_Gothic_Armada_2/
¯¯¯¯¯¯ protontricks -s <search_term>
Found the following games:
Grand Theft Auto V (271590)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.
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.
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.
Please no. I am glad that steam uses only numbers. That avoids capitalization issues when moving stuff between linux and windows.
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.
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?
Yes, though Steam may go to lengths to prevent games on their platform from having the same name.
Edit: this apparently happened with Prey 2007/2016, and resulted in two games installing to the same folder.
find /some/place -type d -mtime 0
Example: https://www.pcgamingwiki.com/wiki/Yakuza_3_Remastered
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).
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 ).
Are there any performance implications?
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.
From the 480 there was the 580, Vega 56/64/VII, RX 5700 and now the 6800.
From a few random benchmark site checks online the 6800 is over three times faster than a 480.
Admittedly, to actually buy a 6800 series it is probably at least three times the price of a new 480.
For oculus it won't work because it requires the oculus windows app.
(Even when you use SteamVR with an Oculus, actually it's using Oculus app behind)
There are also some projects to reverse-engineer / implement open tracking for VR headsets : https://monado.freedesktop.org/#supported-hardware
[0] https://github.com/frostworx/steamtinkerlaunch
[1] https://github.com/frostworx/steamtinkerlaunch#Side-by-Side-...
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.
VLC also works for me from the start, but seems to lag at higher resolutions, hence fiddling to get DirectShow 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.
[0] https://boilingsteam.com/the-valve-index-on-linux-on-a-min-s...
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.
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.
The only reason I still keep Windows dual booted is the Office suit, which is still unbeatable.
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.
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
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.
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.
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.
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.
The PC has largely taken a backseat to consoles. It's a bit much asking for Linux native, let alone, Linux ports.
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.
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.
On the other hand I have now seen multiple games where the developers were implementing wine specific bugfixes.
I think it goes both ways: Showing willingness to support at least proton/wine will also net you some additional sold copies.
And being unfriendly towards linux users is probably more bad PR nowadays than it used to be.
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...
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
On the other hand Wine probably has better backwards compatibility with old Windows games that Windows does in many cases.
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.
I’m not in this area professionally so maybe I have a few things wrong here.
Port /= native client.
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.
There are obviously exceptions, but IME they are quite rare.
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.
On the other hand Wine probably has better backwards compatibility with old Windows games that Windows does in many cases.
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.
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.
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.
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.
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.
I doubt that this is generally true based off the discussions I've seen in the Steam forums for various games.
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.
Win32/Proton is almost like a framework game developers can target and not have to worry about OS specifics.
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.
Aren't there some security benefits from trying to confine apps to user land?
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.
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.
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.
Can’t say the same for many other anti-cheat games though.
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.
Example: https://na.leagueoflegends.com/en-us/news/dev/dev-null-anti-...
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)
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? :(
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.
> 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 serverKeep 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.
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!
All the problems listed above are purely ProtonDB issues. It would be worth reaching out to the ProtonDB admin - he's very receptive to feedback.
However, as a regular user, I assumed ProtonDB was also Valve, and that will be the main contact point for many.
Nothing about the site to me suggests that it is official.
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.
True though, this functionality could do with fixing on the Windows side before we can expect it to work via proton.
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.
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.
1. https://steamcommunity.com/app/1145360/discussions/0/1639794...
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.
[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.
The point is that you should stay critical. People love to glorify the Linux userbase when Linux is often not a economical option.
You will find a lot of stories about it on google. Here is one: https://steamcommunity.com/app/332250/discussions/0/49463250...
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.
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.
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 don't have to imagine: I play Steam games on Windows.
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 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.
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.
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?
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.
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.
IIRC, it's a fork of WINE
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.
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.
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.
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.
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.
But a service that offers my Steam library via cloud streaming would be a very tempting offering.
Additionally the OUYA had some mind share and Valve was pushing Steam Machines and their Steam link so a non windows OS to run on them made sense.
On reflection perhaps the Steam Machines and link were a response to the Windows Store as well but I cant remember the timelines that well.
Good news is that didn't happen and Valve continued to improve gaming on Linux for everyone for free anyways.
SteamOS kernel with commits from Valve devs: https://github.com/ValveSoftware/steamos_kernel/commits/brew... SteamOS compositor with commits from Valve devs: https://github.com/ValveSoftware/steamos-compositor/commits/...
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.
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.
1. https://www.easy.ac/en-us/support/game/guides/os/
edit: Included EACs unabbreviated form as well as a link to supported operating systems.
Someone knows his plextor
> EAC or other anti-cheat technology
What does the E stand for here?
OK I googled for the various other community members that don't know this particular acronym:
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?!
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.
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.
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.
- 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"!
That doesn't mean it should be more invasive, but it doesn't work fine.
But my original point is that you don't need Kernel based spyware to do anti-cheat.
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.
I've tried https://github.com/ValveSoftware/Proton/wiki/Using-a-NTFS-di... to no avail.
Your link is missing a `/` between `Proton` and `wiki` btw.
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!
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!
With these in place, the controllers work 100% great for any controller game.
I probably will end up going down this path though.
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.
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.
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'.
(Not asking you to do research on demand, just in case you already know...)
Steam Play is part of the Steam client, so is proprietary. ProtonDB isn't open source but does data dumps to github regularly [3].
[0] https://github.com/ValveSoftware/Proton/
[1] https://github.com/doitsujin/dxvk
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.
I think this will make game preservation easier in the near future.
I can't say that I recommend the nouveau drivers for gaming.
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.
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.
There are unofficial forks of Proton doing important work too.
amd ryzen + rx580 + archlinux + swayvm + wayland (no xorg)
Edit: obviously with proton
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).
A library intending to implement a Direct3D API support, on top of the Vulcan API.
If I fork Proton as Neutron and add support for 1 game, no one will say "Neutron has enabled 7001 games". It enabled only 1.
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'.
> 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"
In theory yes, but.. some games require specific wine versions, others need special settings on either side, and at times one needs to patch the game.
This is enough to make many games unplayable under wine (for most people), but useable via Proton or a similar wrapper.
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):
./memtest 10000 1000000
memcpy took 0.575571 seconds
memmove took 1.082038 seconds
FreeBSD (2.0Ghz AMD Athlon64 3000):
./memtest 10000 1000000
memcpy took 1.487334 seconds
memmove took 1.442741 seconds
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.
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
https://github.com/flatpak/flatpak/issues/3797
"Recent versions of Steam can optionally put each game in its own container, using a Flatpak-derived tool named pressure-vessel."
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.
https://www.gnu.org/philosophy/funding-art-vs-funding-softwa...
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.
[1]: https://github.com/valvesoftware/steam-for-linux/issues/3671