It's Now Been Six Years Since Valve Began Rolling Out Steam For Linux

[LinAGKar]

I’ve had a few bugs, mainly in Unity-based games, related to non-English locale. Games do some funny things with parsing floating-point numbers, and when the decimal separator is set to comma, and not a dot, they hang, change some in-game shop prices in absurd ways, or simply crash (such problems were present in, among others, Oxygen Not Included, Pillars of Eternity). Nothing that setting LC_ALL=C would not fix, but it is annoying and one has to know what the problem is and how to fix it. I haven’t seen similar issues reported on Windows. And as these problems do not happen on English-language systems, there is relatively little help about them on the net…

You can thank C# for that. Apparently some moron at Microsoft decided to make float.Parse act differently depending on the locale, and have it throw an exception if the locale is something different than what the devs expected.

[silmeth]

I’ve had a few bugs, mainly in Unity-based games, related to non-English locale. Games do some funny things with parsing floating-point numbers, and when the decimal separator is set to comma, and not a dot, they hang, change some in-game shop prices in absurd ways, or simply crash (such problems were present in, among others, Oxygen Not Included, Pillars of Eternity). Nothing that setting LC_ALL=C would not fix, but it is annoying and one has to know what the problem is and how to fix it. I haven’t seen similar issues reported on Windows. And as these problems do not happen on English-language systems, there is relatively little help about them on the net…

But, besides locale-related problems which suggest that both engine and game devs test only on en_US.UTF-8 systems, I have encountered almost no problems with native Linux games (I had some minor ones with game updates introducing new bugs, but I think those things happen equally often on Windows). So, for me, it basically just works™.

[oiaohm]

It's been some time since I tried debugging an issue all the way down (since I have windows too) but last two I remember were:

1. dbus crash on interface changes
2. pulseaudio related crash with some incompatibilities

It might be that #2 was not a library issue but similar to the dbus one a sort of message format issue, not sure, it's been some time. But even then you can have a situation where a compile time switch in lib1 which depends on lib2 can cause a crash if lib2 hasn't been compiled in a specific manner as well. It's a mess.

Pulseaudio one I saw a few bugs on steam-runtime issue list. Most were too old pulseaudio interface library in the steam runtime it mixed with newer bad things use to happen.

Steam-runtime in recent years is a lot better than it use to be.

I have not seen a bug in the issue list on the steam-runtime that in fact traced to library compiled option.

Really I have not seen any issues reported against the steam runtime that traced to library compiler flags.

[Almindor]

libcapsule work should address a lot of this. As this will allow splitting host libraries from steam package libraries.

https://git.collabora.com/cgit/user/vivek/libcapsule.git/tree/README

I have not see issues with the steam runtime with complile-time switch. Straight up version conflict with libraries yes. Where application expects older library and will not tolerate newer. Arch did give you a lot more newer libraries.

It's been some time since I tried debugging an issue all the way down (since I have windows too) but last two I remember were:

1. dbus crash on interface changes
2. pulseaudio related crash with some incompatibilities

It might be that #2 was not a library issue but similar to the dbus one a sort of message format issue, not sure, it's been some time. But even then you can have a situation where a compile time switch in lib1 which depends on lib2 can cause a crash if lib2 hasn't been compiled in a specific manner as well. It's a mess.

[oiaohm]

some steam-packaged library being compiled with some compile-time switch that won't work with a dependency library on the system etc.

libcapsule work should address a lot of this. As this will allow splitting host libraries from steam package libraries.

https://git.collabora.com/cgit/user/vivek/libcapsule.git/tree/README

I have not see issues with the steam runtime with complile-time switch. Straight up version conflict with libraries yes. Where application expects older library and will not tolerate newer. Arch did give you a lot more newer libraries.

[Almindor]

~50%? Wow , your luck is crap. For me, native games worked ~99%. The only game I had problems with was War Thunder and it got fixed. And a lot of those problems were due to my meddling.

Yeah, for me it's ~50% and most of the time they just crash. Now granted I am on Arch which is not officially supported but that still tells you how much of a mismatch game the library hell on Linux is. Most of the time the crash is something funny-stupid like dbus message format incompatibility (coz the game is set to listen on an ancient dbug interface version) or some steam-packaged library being compiled with some compile-time switch that won't work with a dependency library on the system etc.

Just, you know the usual linux library hell.

[makam]

Six years in, are you happy with the direction of Linux gaming?

While really thankful to Valve for all they did I have to say no. Native linux games (e.g. ported, not proton supported) are ~50% chance of outright failing, streaming doesn't work between nvidia and AMD machines (linux to linux but also windows to linux). Proton is almost as bad hit and miss as the "native" games, although honestly I think it might be the ticket to get things in a better shape.

~50%? Wow , your luck is crap. For me, native games worked ~99%. The only game I had problems with was War Thunder and it got fixed. And a lot of those problems were due to my meddling.

[pmorph]

It's gonna be the king of irony if Proton ends up being "the way" to have stable games on linux. Given the linux userspace mess, I wouldn't be surprised.

With the ever icreasing rate of change in IT, it could be that solutions like proton end up being the sane way to run any application software at all on modern systems. That, or sticking to left behind, legacy tech.

[moilami]

I am happy and I think over time Linux will become technically strong in gaming and challenge Windows. That does not mean masses will move to Linux, though.

[schmidtbag]

Cool, but i used WINE for games since i think 0.9.x versions back in year 2006. so it is not a new thingie to me

Understood; I wasn't suggesting there was anything new. My point was more that Proton isn't just simply a re-branded Wine. It does function a little differently, and it removes a lot of the headaches involved in trying to install Windows games on Steam without needing the Windows version of Steam, as well as any of those other hacks that may threaten your account. So, it is a little different than what you may be used to.

They should push for native games and users should consider this just as a bonus, as WINE and Proton won't ever be perfect really

I 100% agree, but, Proton is at least a step in the right direction to encourage people to ditch Windows. Alluding to what I was saying before, using Wine to play Steam games has never been the most user-friendly experience, and it also hurts the statistics of the Steam survey.
Incentivizing devs to port their games to Linux is just one of many objectives to improve the overall Linux gaming ecosystem. Through Proton, people (like myself) can fully ditch Windows with relatively minimal effort. Getting rid of Windows is a major step forward to show publishers that people would use Linux if it were more compatible.

So far, this is proving to be true - the Steam survey is showing Linux users on the rise since Proton was released. It's not a big improvement, but, Valve also hasn't done much advertising with this, either (nor should they, since it isn't totally stable). I'm sure there are thousands of Windows gamers open to using Linux who aren't aware of Proton.

Anyway, I've mentioned this in another thread but I'll say it again: I think the best course of action for Valve is to improve the profit margins of devs who focus on Linux compatibility. So for example, let's say Valve gets 30% of the revenue for every game sold. If a dev/publishers tries getting a game on the Proton white-list, Valve would reduce their cut to maybe 25%. If the game has a native Linux port but isn't very well optimized, Valve reduces their cut to 20%. If the game is ported natively and performs roughly as good as it does in Windows, Valve reduces their cut to 15%. It doesn't matter whether the game is sold in Windows or not, those percentages will drop regardless. The point is so the publisher doesn't feel like they're wasting time and money on porting, so even if the game never gets sold in Linux, their expenses are still covered from Windows users.