Gaming on Linux 2019 | A GNU Era of Gaming

OP
OP
Nappael

Nappael

Member
Oct 25, 2017
5,180
Now that's something interesting I didn't know! I only use 60hz so never noticed.

It seems it's something particular with Proton, as Wine through Lutris works just fine. I hope this gets addressed.
 

Toast

Member
Oct 28, 2017
151

I’m sorry that we’ve given anyone the impression that we are “dropping support for i386 applications”. That’s simply not the case. What we are dropping is updates to the i386 libraries, which will be frozen at the 18.04 LTS versions. But there is every intention to ensure that there is a clear story for how i386 applications (including games) can be run on versions of Ubuntu later than 19.10.
Dropping updates? That wont work well...
 

eonden

Member
Oct 25, 2017
3,458
Taking into account how one of their devs did a public experiment of how games from GOG would run and it failed BIG TIME, I think that is part of the backtrack... but yeah, dropping updates is not gonna end well.
 

itsamiracle

Avenger
Oct 27, 2017
1,451
GOG builds are especially finicky, probably due to the way they distribute the linux versions. A couple games like Shadwen refuse to work unless you jump into the lib mismatch hellhole.
 
OP
OP
Nappael

Nappael

Member
Oct 25, 2017
5,180
Taking into account how one of their devs did a public experiment of how games from GOG would run and it failed BIG TIME, I think that is part of the backtrack... but yeah, dropping updates is not gonna end well.
To be honest, the fact that they seemingly didn't want to test that before making that insane announcement makes me wonder just how little they thought the whole thing through. It was one of the very first things I thought of.

The new backtrack could work in theory (if they figure out the whole mixed library multiarch issue), but having things like 32 bit Mesa locked to old versions will end up causing performance issues after a while. I still think that if gaming is what you want, Ubuntu now seems like a bad choice.
 

Dave.

Member
Oct 27, 2017
1,206
Sooo I just found out that Proton doesn't work at high refresh rates. All Proton games I launch are locked at 60 Hz. That's a complete deal breaker. Valve hasn't even answered to the issue on github :(
Reading that issue it seems a little more nuanced than that?
- only when vsync enabled?
- not all games - many will show 60Hz, but run at the desktop refresh rate anyway
- can use wine-tkg to build a WINE with Proton patches but not the "Proton Fullscreen hack" (source of the issue)

Still, would be nice to be fixed officially I'm sure.
 

spool

Member
Oct 27, 2017
328
I've been playing Mirror's Edge with Proton on my 144hz monitor and get 100-144fps according to Steam's counter. vsync on or off doesn't seem to matter.

I haven't really gotten much use out of my new monitor though, I need to research my library to see what I own that I can realistically get to run at 144.

I'm honestly not even sure if freesync is even working. I'm not getting that wow effect people are always talking about, at least.
 

eddy

Member
Oct 25, 2017
766
I haven't really gotten much use out of my new monitor though, I need to research my library to see what I own that I can realistically get to run at 144.
You're getting use of it just on the desktop. Compare dragging a window around at 60Hz vs 144Hz. Should be very noticable difference.
 

Xharos

Member
Oct 25, 2017
3,643
Canary Islands, Spain
Reading that issue it seems a little more nuanced than that?
- only when vsync enabled?
- not all games - many will show 60Hz, but run at the desktop refresh rate anyway
- can use wine-tkg to build a WINE with Proton patches but not the "Proton Fullscreen hack" (source of the issue)

Still, would be nice to be fixed officially I'm sure.
Yeah, I saw that apparently some games work at 144 FPS despite it, just not any of the ones I tried. Still, valve needs to provide a command line option to disable the Proton Fullscreen Hack, that would pretty much solve the issue. If a game refuses to go past 60 FPS with the hack, I'll just disable it for that particular game. Having to straight up build Protin by myself, tho? Naaah...
 

thebishop

Member
Nov 10, 2017
1,441
I don't think that the target distro for the Valve's Steam client package and what distro SteamOS is based on are really related the way you're suggesting. For starters, the Steam client package Valve provides is for Ubuntu, and SteamOS is based on Debian, as you say, so it's not like they're the same today either.

By providing a Flatpak, instead of a package that's suitable for some other single distro, they dramatically increase the number of Steam users who are going to be able to use the Valve provided package instead of some repackaged version from a third-party repo, and they're no longer at the mercy of bad decisions made by the any single distro.

In any case, if having the environment the Steam client is run in and SteamOS be similar is a goal, Flatpak actually gives them a way to do that much more effectively. If they maintain their own Flatpak runtime based on the SteamOS userspace, then everyone using the Steam flatpak will be running it in an environment almost identical to SteamOS, regardless of what distro they use.
For end users, I totally agree. Flatpak would be a great distribution option. I don't know what Valve's goals are, but I don't think the Linux desktop effort would be worth it (for them) if they weren't still planning to make SteamOS a viable next gen "console" option. It's not like I'm arguing against it, I'm just not optimistic they're gonna do it.
 

thebishop

Member
Nov 10, 2017
1,441
Isn't Fedora a bleeding-edge OS? Seems like the opposite of what they'd want if they're looking for some peace and quiet, and of course there's no guarantee Fedora wouldn't do the same thing.


OpenSUSE has like no mindshare AFAIK, unless they're super-popular in some region (germany?).
Lol I agree with you about OpenSuse. But yea I think it does have more support outside the US.

As for Fedora, the "rawhide" flavor is a rolling, bleeding-edge distro, but the mainline versions are intended to be stable (imo more stable than recent Ubuntu releases).
 

spool

Member
Oct 27, 2017
328
You're getting use of it just on the desktop. Compare dragging a window around at 60Hz vs 144Hz. Should be very noticable difference.
No, there really isn't. I'm a dual monitor user, and my second monitor is 60hz. I can drag a window around across the monitors, and straddle it across them and move it up and down, and there is no difference that I can perceive. But Ubuntu's Gnome desktop is stuttery garbage at all times, so I don't think it's a good test. Games are MUCH smoother than Ubuntu's desktop, even at 60hz.
 

eddy

Member
Oct 25, 2017
766
And Canonical has changed course and will now continue to support (select) 32bit packages, but maintain they have to go in the long term.

I hope solutions are ready when the time comes, as opposed to presenting us with vague "containers should work, probably, the community will fix it" stuff.
Right, so instead of placing the burden on the people shouting the loudest that 32-bit support is important in 2020 and beyond, it now goes back to Ubuntu maintainers in general.

Seems like a bad decision to me.

Obviously there's basically zero incentive for anyone to work on this if Canonical keeps the status quo. You think Valve is going to lift a finger? Doubt it.

This one will come around again, and nothing will have changed, except there'll still be a 32-bit steam client for some fucking reason.
 

Elfforkusu

Member
Oct 25, 2017
2,813
Right, so instead of placing the burden on the people shouting the loudest that 32-bit support is important in 2020 and beyond, it now goes back to Ubuntu maintainers in general.

Seems like a bad decision to me.

Obviously there's basically zero incentive for anyone to work on this if Canonical keeps the status quo. You think Valve is going to lift a finger? Doubt it.

This one will come around again, and nothing will have changed, except there'll still be a 32-bit steam client for some fucking reason.
Valve will lift a finger by dropping Ubuntu support. It's the distro's job to provide system libraries, if Ubuntu doesn't want to support wine/etc by doing that, they're essentially just taking the BSD route. It's their business, if they want to abandon desktop users that's fine. But that's what dropping multiarch means.

Anyway, I'm happy they backed off. Hopefully they have a come to Jesus moment in the next year or so, but I doubt it.
 

eddy

Member
Oct 25, 2017
766
Valve will lift a finger by dropping Ubuntu support. It's the distro's job to provide system libraries
Yeah, they sure as hell wouldn't manage to release a 64-bit client, that's way too much effort.

(Anyone who thinks Valve is worried about random 32-bit game binaries breaking probably need a reality check)
 

Xharos

Member
Oct 25, 2017
3,643
Canary Islands, Spain
Yeah, they sure as hell wouldn't manage to release a 64-bit client, that's way too much effort.

(Anyone who thinks Valve is worried about random 32-bit game binaries breaking probably need a reality check)
Why shitpost? Valve already released a 64-bit client on MacOS, they're very likely working on a Linux and Windows one as we speak, and yes, they are probably very worried about, dunno, 70% of Steam's library breaking? Including Valve's own games unless they've been updated and I missed it.
 

eonden

Member
Oct 25, 2017
3,458
Valve is not worried about a 64-bit client, heck parts of the client already are 64-bit (such as the chat and the upcoming library UI) as they will be Electron apps. Heck, they have already oficially dropped support for XP and Vista (the real major x32 OS left as W7 x32 is ... weird).

The problem is not the app becoming x32, but rather having a huge repository of games (and parts of Proton) thrown away.
 

eddy

Member
Oct 25, 2017
766
Why shitpost? Valve already released a 64-bit client on MacOS, they're very likely working on a Linux and Windows one as we speak, and yes, they are probably very worried about, dunno, 70% of Steam's library breaking? Including Valve's own games unless they've been updated and I missed it.
I don't understand what there is to work on. If they were a bit more open, maybe I could understand how it's possible for them to not have shipped a 64-bit client on linux >ten months after they added support for different binaries to the self-updater. I honestly thought we were weeks away when that happened.

The problem is not the app becoming x32, but rather having a huge repository of games (and parts of Proton) thrown away.
Just so you know, in the context of a linux ABIs "x32" is its own thing, but to your point; what huge repository of linux games are we talking about? What I imagine is something like an original Abuse binary from 1997.

Proton... don't know how it works well enough to have an opinion on whether that's a reasonable complaint. If anything WINE should be the solution, not a blocker. The core magic of Proton is in DXVK which SURELY can not rely on native 32-bit code.

Just to be clear, I don't have a problem with other people running multilib and enjoying their weird 32-bit binaries, all I want is to be able to run steam and not have to pollute my system with i386 libs.
 
Last edited:

Xharos

Member
Oct 25, 2017
3,643
Canary Islands, Spain
I don't understand what there is to work on. If they were a bit more open, maybe I could understand how it's possible for them to not have shipped a 64-bit client on linux >ten months after they added support for different binaries to the self-updater. I honestly thought we were weeks away when that happened.



Just so you know, in the context of a linux ABIs "x32" is its own thing, but to your point; what huge repository of linux games are we talking about? What I imagine is something like an original Abuse binary from 1997.

Proton... don't know how it works well enough to have an opinion on whether that's a reasonable complaint. If anything WINE should be the solution, not a blocker. The core magic of Proton is in DXVK which SURELY can not rely on native 32-bit code.
Wine needs 32 bit Linux libraries in order to run 32 bit Windows games. If you think 32 bit games are 1997 stuff then you don't really know what you're talking about. Most games from the PS3 / 360 era were 32 bit only.
 

eddy

Member
Oct 25, 2017
766
Wine needs 32 bit Linux libraries in order to run 32 bit Windows games.
Why? Does it need a 32-bit kernel too, or did we just put the border at the wrong place? In my head you'd provide a 32-bit shim to handle ABI issues if that's a thing, and the call out to the 64-bit implementation(s).

If you think 32 bit games are 1997 stuff then you don't really know what you're talking about. Most games from the PS3 / 360 era were 32 bit only.
Again, the context is linux games. Unless you're saying proton can take PS3 binaries I fail to see the relevance. No need to artificially inflate the problem space here, let's focus on actual binaries.

Someone ran a test? There's a list somewhere?
 

eonden

Member
Oct 25, 2017
3,458
Why? Does it need a 32-bit kernel too, or did we just put the border at the wrong place?



Again, the context is linux games. Someone ran a test? There's a list somewhere?
From a Canonical dev:


The 32 bit Linux libraries are more important than you believe.
 

Xharos

Member
Oct 25, 2017
3,643
Canary Islands, Spain
Why? Does it need a 32-bit kernel too, or did we just put the border at the wrong place? In my head you'd provide a 32-bit shim to handle ABI issues if that's a thing, and the call out to the 64-bit implementation(s).
I have no idea. I'm not a programmer. The fact it that that's how it works. You need multiarch to use 32 bit Window programs under Wine / Proton.
Again, the context is linux games. Unless you're saying proton can take PS3 binaries I fail to see the relevance. No need to artificially inflate the problem space here, let's focus on actual binaries.
...you know I mean PC games released during the PS3 / 360 era. And that includes Linux versions of these games, for the most part.
 

eddy

Member
Oct 25, 2017
766

The 32 bit Linux libraries are more important than you believe.
It's a good start, but multiple of the failures could be things that are relatively easy to fix, e.g when he got "Game is a black window - suspect this is poor OpenGL support in VirtualBox". The wine failures are what they are, the real question there is why you couldn't have an AMD64 Wine32. That boundary seems... convenient.

Pure 32-bit ELF binaries, yes, those won't run without some layer of simulation, of couse. Many could no doubt see a re-releases if there was some pressure to do so, like Braid. Though Jon is a bit of a moaner. (Just kidding Mr. Blow, looking forward to trying Jai!)
 

zoku88

Member
Oct 27, 2017
428
This article explains how 32 bit binaries work on 64 bit kernels.


Which is why you don't need a 32 bit kernel.

As far as libraries go, how would a 32 bit binary even load a 64 bit library? They're not compatible.

As far as release of games.. There were still 32 bit games released last year. Pretty sure the superb 428 is one of them.
 

eddy

Member
Oct 25, 2017
766
...you know I mean PC games released during the PS3 / 360 era. And that includes Linux versions of these games, for the most part.
I do, but I don't think too many of those became linux releases so by bringing them up you are in effect projecting the problem space so it looks much much larger than it probably is.

Starting to find the conflation of Win32 PE binaries and linux binaries annoying. There's no natural connection between the foreign format and the native one that makes it so they have to have the same 'bitness'. 'WINE' is the natural border, and it not (apparently) being able to run Wine32 on a 64-bit system, or whatever the issue is there, smells like a result of convenience and time.

Maybe there are real (good) technical issues as to why you'd need i386 linux libraries to run 32-bit Win32 PE executables, I just can't think of why. Perhaps something in my understanding of not-emulator-Wine is wrong.
 
Last edited:

eddy

Member
Oct 25, 2017
766
As far as libraries go, how would a 32 bit binary even load a 64 bit library? They're not compatible.
For native code, no they're not. There's a real 'loss' there. In the context of wine/proton, surely we control LoadLibraryA() and family?

As far as release of games.. There were still 32 bit games released last year. Pretty sure the superb 428 is one of them.
I'm sure there'll be more for as long as multilib is a thing, every year adding more titles that will eventually/potentially be lost.
 

Elfforkusu

Member
Oct 25, 2017
2,813
I do, but I don't think too many of those became linux releases so by bringing them up you are in effect projecting the problem space so it looks much much larger than it probably is.

Starting to find the conflation of Win32 PE binaries and linux binaries annoying. There's no natural connection between the foreign format and the native one that makes it so they have to have the same 'bitness'. 'WINE' is the natural border, and it not (apparently) being able to run Wine32 on a 64-bit system, or whatever the issue is there, smells like a result of convenience and time.

Maybe there are real (good) technical issues as to why you'd need i386 linux libraries to run 32-bit Win32 PE executables, I just can't think of why. Perhaps something in my understanding of not-emulator-Wine is wrong.
I'd say the main problem with your understanding of this stuff is that your understanding is nonexistent? I'm not sure what your background is, but at least on this page you're trying to speak with authority on a subject you are very clearly clueless on. Please stop? (or learn and come back?)
 

Toast

Member
Oct 28, 2017
151
^ I don't know man, we need an outreachy or code of conduct article to see if it goes as low as phoronix.
 
OP
OP
Nappael

Nappael

Member
Oct 25, 2017
5,180
The code of conduct response was a farce and I really would prefer we not go in that direction.

Anyone here tried Jupiter Hell? It seems really interesting and they run a test last weekend.
 

nded

Member
Nov 14, 2017
3,870
Put Pop!_OS on my new AMD build today and I'm really enjoying it because my RX590 fans seem to work correctly in it unlike an earlier Ubuntu install. I look forward to breaking it in 6 months time and switching to yet another distribution in frustration.
 

itsamiracle

Avenger
Oct 27, 2017
1,451
Hhm, this is the diversity month version of Debian's emblem

If they are ever decide to update the swirl, it wouldn't be a bad base to use for the new version.
 
OP
OP
Nappael

Nappael

Member
Oct 25, 2017
5,180

One thought I had. I wonder if the significantly reduced shader compile times could be used to further reduce stutter for AMD users using Proton/DXVK.
 

itsamiracle

Avenger
Oct 27, 2017
1,451
A recent steam beta update mentioned something about opengl/vulkan shaders, don't recall if it was related to that
 

hikarutilmitt

Member
Dec 16, 2017
2,583
Dagnabbit sunnuva biscuit.

The recent wine-mono changes in Proton 4.2-8 seem to have broken Fight n Rage. It was working fine on previous versions but now it crashes if you leave it on the play buton for long enough or right after it begins the CPS-style bootup screen and crashes right after the first rom check shows up. there' an entry on ProtonDB that says to just run protontricks and install dotnet40 but it doesn't work and prevents the game from even loading to the play screen like it used to.

I wish it were possibly to select particular old versions of a branch either as a standalone or as a beta build in case it breaks something drastically.
 

zoku88

Member
Oct 27, 2017
428
If you go to the game properties, you can select a particular version of proton to use with the particular game
 

nded

Member
Nov 14, 2017
3,870
Dagnabbit sunnuva biscuit.

The recent wine-mono changes in Proton 4.2-8 seem to have broken Fight n Rage. It was working fine on previous versions but now it crashes if you leave it on the play buton for long enough or right after it begins the CPS-style bootup screen and crashes right after the first rom check shows up. there' an entry on ProtonDB that says to just run protontricks and install dotnet40 but it doesn't work and prevents the game from even loading to the play screen like it used to.

I wish it were possibly to select particular old versions of a branch either as a standalone or as a beta build in case it breaks something drastically.
Winetricks dotnet40 worked for me. Seems to have regressed to how it was in 3.16, I even had to click the window to make the game start.

If you go to the game properties, you can select a particular version of proton to use with the particular game
Problem is the version that worked with Fight n Rage is 4.2-6 which is superseded by 4.2-9 in the selection menu.
 
Last edited:

hikarutilmitt

Member
Dec 16, 2017
2,583
Winetricks dotnet40 worked for me. Seems to have regressed to how it was in 3.16, I even had to click the window to make the game start.


Problem is the version that worked with Fight n Rage is 4.2-6 which is superseded by 4.2-9 in the selection menu.
That's why it's annoying me, it doesn't even launch after doing that. I've had to manually kill the process for each workaround I've tried.
 

hikarutilmitt

Member
Dec 16, 2017
2,583
Have you tried deleting the Proton prefix in the compatdata folder and generating a fresh one?
Yeah, I went through the old steps that used to work prior the the previous wine-mono update.It just refused to work. I just went and set the proton version to 3.16 branch and did the old steps and it worked, so I'll hold it there util a newer revision fixes it again.
 

Crayon

Member
Oct 26, 2017
9,545
Battletech. Finally found a game i can settle with after straining my hand playing fighters and shooters for a whole month.

I'm not even sure if it's actually that good or I'm just blinded by my battletech fancy. At first I found it pretty clunky, and the tightly directed missions disappointing, but after a couple hours it really gets down and dirty with the mercenary management game. So fun.

I'm playing it on TV with the steam controller setup to favor the left hand lol.
 

itsamiracle

Avenger
Oct 27, 2017
1,451
Yeah, Canonical folks had hinted about working on getting the latest drivers easy to install a couple months ago. Good to see them making it happen.