Hacker News new | past | comments | ask | show | jobs | submit login

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.


Would you mind sharing the name of your game? I'm saving up to buy some games soon, and I'd like to support cool devs like you!


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

https://store.steampowered.com/app/1200710/BadLads/


Thanks for replying; it looks really great! I just purchased it, and I hope to play it over the weekend!


This looks really cool. From the description is sounds a bit like DarkRP in Garry's Mod. I remember having a lot of fun with that mode.


To me it sounds like a GTA San Andreas multiplayer server.


Did you consider requiring Steam Linux Runtime? The most recent versions use containers so that even glibc will be a fixed version.


AppImage to the rescue! (https://appimage.org/)


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


>> Most Linux ports sucked anyway

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.


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.


>> for first-class linux ports?

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.


I have never viewd it that way, but you are absolutely right about the danger.

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.


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.

https://github.com/ValveSoftware/Proton


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


Hell, now we're starting to see ports of mobile games to PC platforms, with all the same weirdness.


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.


Even if devs don't make native ports they would still work on improving compatibility with Proton as long as there are fresh Linux players


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.


>a disproportionately vocal minority comprising <1% customers but >50% of bug requests

I doubt that this is generally true based off the discussions I've seen in the Steam forums for various games.


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.


How good does this work with things like Oculus Quest, SteamVR, etc.?

Are there any performance implications?


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.


That's my thinking too. I have my VR hardware (2 tracker things+headset) on a power bar that I turn on separately after boot.


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.

[0] https://boilingsteam.com/the-valve-index-on-linux-on-a-min-s...



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.


It is almost 5 years old and several generations back. Perhaps not "ancient" but it's aging.

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.


Maybe the Valve Index works through SteamVR ?

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


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.

[0] https://git.dec05eba.com/vr-video-player/about/


Uh! Never found this one despite extensive googling. I'll install it and report back.


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

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


I've been using Skybox on steam vr on linux, and it seems to work consistently for viewing local video files, whether flat or side-by-side.


Doesn't work for me on Ubuntu 20. I've bought pretty much all those available on steam.


I use Whirligig, which works with a minor fix documented on ProtonDB.


Whirligig does not work for me with the recommended fix.


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.


Oh yeah, that's a fair point, I have encountered the input lock issue before. Hopefully it will be fixed in future.

VLC also works for me from the start, but seems to lag at higher resolutions, hence fiddling to get DirectShow working.


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.


Wayland with Nvidia works in fedora 33, you just have to un-blacklist the driver.


I'll have to take a look at that later- thanks! Every time I revisit this there's some issue.


It seems to be working but performance is worse than when using x11. it's quite usable but I'm switching back for now.


I'm in the same camp because a lot of devs that say they have Linux support don't always support it well.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: