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.
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.
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.
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.