Native Linux Gaming Has Problems …
ฝัง
- เผยแพร่เมื่อ 23 ก.ค. 2024
- I wanted to compare the performance of native Linux games against their Windows version on Linux with Proton. Unfortunately, I discovered that native Linux gaming has its problems. But see for yourself.
PC Specs:
CPU: Intel Core i3 12100f
GPU: AMD Radeon RX 6600
RAM: 16 GB DDR4 3200
SSD: 1 TB Samsung 970 EVO Plus
OS: Ubuntu 24.04 LTS
Surface Go Specs:
CPU: Intel Pentium 4415Y
GPU: Intel HD Graphics 615 (iGPU)
RAM: 8 GB
SSD: 128 GB
OS: Ubuntu 24.04 LTS
Timecodes:
00:00 Intro
00:24 What is Proton?
00:45 Problems with native games
3:04 Benchmarks native vs. Proton
3:51 Outro - เกม
As some of you pointed out, the Steam Runtime already includes all the necessary libraries. The statement in this video about the changed or missing libraries is not entirely correct, but not wrong either. Because I don't want to answer every comment individually, here are a few statements:
1. According to the Steam/Troubleshooting Arch Wiki (2.1) missing libraries are even in the Steam Runtime a thing. wiki.archlinux.org/title/Steam/Troubleshooting
2: Quote from a document from the Steam Runtime repository: "If the library is not provided by the Steam Runtime, then the version from the operating system or user configuration is used." gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/ld-library-path-runtime.md
3. Even if the libraries were absolutely not a problem, the statement about the problematic backwards compatibility would still be true. For example, If a native Linux game was released in 2020 when X.Org was still the standard, it may no longer work under XWayland today, such as Metro Exodus. You can still switch to X.Org, but at some point only Wayland will be available as standard in current distributions. Maybe I should have said system components instead of libraries. But the problem is the same.
Thank you for taking the time to watch the video and comment. I learned something about the Steam Runtime from your comments that I should have researched before making the video.
Just curious, as a newcomer to development and Linux, what if a program was statically linked? Would the problems with libraries not be there with that, or would that cause other problems?
I think these two wiki articles from Fedora and Gentoo sum it up well:
fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries
wiki.gentoo.org/wiki/Why_not_bundle_dependencies
@@LowBudgetLinuxGaming Having read them just now, yeah makes sense. Though, I could only imagine how complicated it would be to keep up with the libraries then.
Thank you for replying and pointing in the right direction
I switched from Windows 11 to Fedora 40 KDE recently. I can't complain about gaming performance under proton at all, there is almost no difference. The main game I tested was cyberpunk, i had basically the exact same fps and everything worked well. But in other games, there can be some lagspikes (like you mentioned, the 1% lows) and even some minor graphical glitches, like screen space reflections not working properly. But all in all, it is pretty usable, except for all the random other problems Linux likes to throw at you if it notices youre getting bored with your pc running too well.
When native versions work (as your video illustrated), they can work really well, and often much better than in Windows. For example, Factorio can save a game in Linux and not freeze, impossible in Windows, and runs so much faster. Other native games I have that seem to run smoother and faster are Cities Skylines and Hearts of Iron IV. However, there are some native games that just won't run, or have major problems, such as Warhammer II (the native version just never launches or used to get multiple segfaults). The problem is Warhammer II was ported to Linux by Feral Entertainment and targeted Ubuntu only, and I'm not running Ubuntu. So Warhammer II is now run under Proton, and it works fine. So perhaps we have the best of both worlds? Often native versions are excellent, but we have an alternative with Proton.
We need to start supporting Linux gaming, I'm tired of Microsoft Monopoly.
i very much agree, but its funny that the easiest way to do that might be developing for Proton/WinE because linux library consistency is a mess. the Steam Linux Runtime should be good enough now though, hopefully. Wayland should be the last huge change for a while.
@@xymaryai8283Same i also hate he fact that ppl who dont know shit just act smart and say that im dumb and that windows is better without giving a real reason to why tbis happens all the time and they just spamm rhe stereotypes that are not even true like that it takes 50k commands tl chnage wallpaper
Fedora Kinoite user here and fr man I had to run most games under proton
And some times I have to switch to windows to run them
Native Games can use Steam's Steam Runtime, which is a bundle of libraries which get shipped by Valve and not depend on system libraries at all, so that is not really a problem.
Thanks for your comment.
Since 3 people have already written here that the statements from the video are not entirely correct, I am thinking about doing a little more research and making a follow-up video. You seem to have a bit more insight, could you please go into a bit more detail. Why do so many native games have problems? Is the problem then with the Steam Runtime?
I showed in the video that there are problems with native games and several people have already commented that they have noticed similar things.
@@LowBudgetLinuxGaming The problem is probably that developers don't invest much into their Linux ports. It still needs polishing and testing. The problem you had with XWayland is probably more of an issue with XWayland rather than the game. I'm not sure how many native games use the Steam Runtime, they absolutely shouldn't use the system libraries, as they are not predictable enough. If they use the Steam Runtime they should just work. We can only hope that native ports get better now that the steam deck is here.
@uwumarie The thing is that many games list Ubuntu as a system requirement. For example SOTTR (Ubuntu 18.04), Metro Exodus (Ubuntu 20), or Desperados III (Ubuntu 20.04). So I assume that they use at least some system libraries.
But even if they use the Steam Runtime exclusively, the fact that a game used to run perfectly with e. g. Ubuntu 20.04 and now doesn't because the default display server is Wayland now, is exactly the point with the backwards compatibility that I tried to make.
Maybe I should have said system components instead of libraries, but the outcome is the same.
Good thing we have Proton now :-)
@@LowBudgetLinuxGamingIt's really not the same. This is very specific to the discrepancy between X11 and Wayland, both the fact that Wayland is being pushed more and more as a default on a few distributions and that games today mostly only support X11. Wayland has XWayland so it's not even a backwards compatibility problem, but for some reason you didn't have it installed, which makes me think that you encountered an Ubuntu migration bug or oversight.
@@LowBudgetLinuxGaming the steam runtime has different versions based on Ubuntu versions, so i would assume they use the steam runtime which matches the ubuntu version
Flatpaks, appimages and proton has been a blessing for linux. I know some purist are against because of some philosophical reason but as you said as we grow older we do not want constant problems.
That said I know some of those technologies have issues but they are fixable, but dependency hell can not be fixed
I think flatpaks and appimages are good for old linux software that is no longer being actively maintained or for complex software with a large amount of dependencies, but for everything else, flatpaks and appimages are unnecessary bloat.
In my opinion, AppImages would be the perfect solution for games. The problem is that most games are commercial closed source products and shipping those with open source libraries can be very expensive in terms of licensing. You don't only have to take into account the licenses of the libraries used, but also the licenses for the libraries used by the libraries and so on. The licence problem as far I know disappears if you link dynamically against libraries that are shipped with the OS.
@@LowBudgetLinuxGaming Appimages are just a way of bundling an application with its dependencies. An appimage can be freely extracted/mounted into a folder and then repackaged, which I believe is compliant with terms as restrictive as those of the LGPL license.
@@harpskid Unnecessary bloat? What's the alternative? Compiling everything yourself? Or forcing developers to create packages for every distro out there? Flatpaks and Appimages are a blessing and should be used wherever possible
@@Henrik0x7F appimages are great
flatpaks are not
i much prefer nix as a universal linux package manager
This is the main problem with Native Linux games, I have games from old days most of them crashes on modern distro due to updated gcc library not compatible with the one game compiled on (old gcc version), the situation is slightly better with nVidia proprietary driver but with Mesa 3D drivers (AMD, Intel) the old games crashes as Mesa 3D drivers highly depended on gcc libraries (ie libstdc++). For example, native game Jack Keane would crash after some time in modern distro with Mesa 3D but not with nVidia proprietary drivers
Na, not even going to complain because this video is totally on point.
Linux was never designed with proprietary software in mind and running old Linux games can be a nightmare. Comparatively running Old windows games on Linux is easier then it is on windows.
the issue is developer time for a niche platform, it just won't happen if there is a good solution as proton, at the end of the day, it doesn't matter as much, is better to be able to run software that potentially will never be updated, like game roms, like windows games
Awesome channel! Keep making these videos man :)
As for the problem, I don't see a solution unless we make Linux into Windows lol, it's a necessary evil I believe.
Something I thought of just now: game devs could include the libraries their games were made with and just use those versions all the time like valve games do
Theoretically this is true. They could probably even ship their game as an AppImage. I have no experience as a game developer, but I know from other software projects I've worked on that shipping open source libraries with a commercial closed source product is quite a licensing mess. The license must be checked for each library individually. But since a library often uses other open source projects, each of these must also be checked. We often had to contact a lawyer who was well versed in the subject.
But if an open source Linux distribution comes with these libraries and a commercial program just links them dynamically, that's usually not a problem.
But that's just my guess. As I said, I'm not a game developer. Maybe it's just a resource problem because native Linux games don't generate enough revenue anyway.
I've always wanted to make a video comparing the native versions vs Proton! Great video!
i prefer devs to focus fully on windows version of games so i can use proton with them instead of them wasting time to half-ass native linux versions
everyone has pointed out the Steam Linux Runtime, but interestingly Proton also uses the SLR (sometimes called pressure-vessel i think) to ensure its environment is more consistent so it can run correctly on various setups, theres a project called ULWGL or umu for short, that aims to recreate this setup outside of Steam for better compatibility, along with other fixes, though its quite a big jump in complexity from my current setup of just running my executables with WinE
Wine which is the parent of Proton, CrossOver for Mac and the backend for many other projects.
I have an SSD lying around and so I decided to make it an external drive after I installed it with pop os. I booted it up on my laptop and I'm new to Linux so I don't know what I have to do to play windows games in it. I just decided to install wine and went straight to boot a game from another external drive. I'm using a laptop, i5 12th gen and Intel iris xe igpu. And I was really surprised that there's no difference in performance between windows and pop os. I played GTA v, Tekken 7, overcooked, Trailmakers, etc. however pop os doesn't produce lightings and shaders correctly because colors tend to have darker tone, like when a character has brown skin, they turn almost black.
I had a Razer Blade Stealth with an 11th gen i7 and an Iris xe iGPU. I had no problems with the iGPU.
If you use Steam you can try different Proton versions or ProtonGE (github.com/GloriousEggroll/proton-ge-custom).
Otherwise try different distros e.g. Fedora 40 or Ubuntu 24.04.
i don't know exactly how well these work under the hood but would anybody mind if they just statically linked their binaries or deploy their native versions in a sort of containerized manner like flatpacks or snaps ?
would that be feasible ?
I don't know anything about game development. But from other software projects I've worked on, there have always been licensing issues whenever open source libraries were used in commercial products. With dynamic linking, this might no longer be so problematic because technically you don't ship the library with your product. But that's just a guess.
Libraries could also have dependencies on certain system components, which could also change.
We've had windows games shipping their own very specific versions of libraries which are duplicates of system libraries for ages yet on linux you can't do that???? Oh wait. You can. I blame developers on that one.
I also had quiet mixed expereince with native linux games. native crosscode has problems with controllers ( right stick isn't read correctly) and baldurs gate has glitched thumbnails for saves ( at least under Wayland).
2:40 No I think that's the whole 'problem' you are trying to present. One funny thing I noticed was the lack of Valve games in testing. If they are the one's making proton, I would sure hope their native builds are much more then most other games. You are correct in that a single compatibility layer is what Linux gaming really needs to succeed, but studios have this option to some degree with the steam Linux runtime.
2:30 not quite, Steam offers the Steam Linux Runtime which solves this problem. However, I do question if these games are even using the runtime. You can force the runtime to be enabled just like you can proton
See the pinned comment
I remember i tried beamng under proton when i load a intensive map it will crash but maps that are not tha intensive
enoying part of proton, is that there are so many of em now, and growing. now you need to test em all, to test who is the best, and working due to the custom patches
Literally the only reason i use windows is games
We Just need oculus and steamvr to work as good as windows and gaming will be peak
I personally don't care if games are native or not, but I wish devs would at least try to ensure Proton compatibility.
A few points. The distribution also matters, Ubuntu/Debian (Ubuntu uses Debian) has older software so that might matter, depending on a number of factors. Just like on Windows you want to use newer drivers for gaming. For native games it is hit or miss, in my experience the older native games of around 2014-2016'ish typically run bettter with Proton than natively. Some games like the latter 2 Tomb Raider games mostly (the snowmap in RotTR is a bit rough, I suspect that the tesellation of the rocks is the cause) work great natively. A good example is Deus Ex Mankind Divided, this game is horribly broken natively and works much better with Proton and dxvk. On that note, some games run a lot better with dxvk than with amdvlk so keep that in mind, examples are Deus Ex MD and StarCraft2 (I had accidentaly amdvlk being used in the past, it was pretty bad for the performance comparatively). So just experiment on a per game basis, try out both if the performance on one is less satisfying and definitely make dxvk the default Vulkan-loader for your games, you can set this with an environment variable. However, some games require amdvlk so if a game does not start then keep in mind to make that game use amdvlk.
Hey, a friend sent this video to me a bit upset, because they thought Linux updates could suddenly break programs after watching this. So I'm leaving this comment because I'm worried this video is a little misleading. I'm gonna leave a pretty lengthy comment here but I hope it'll be clear enough for anyone watching this video to understand.
Just to establish credentials (readers can skip this paragraph), I've worked with both Windows and Linux system APIs - Windows for learning how some types of malware work, Linux for writing a windowing library (specifically with Wayland). I'm not going to claim to be an expert at either but I am familiar with how to read their documentation and I've written code that works with both. I also work as a part-time developer, but my job doesn't involve writing code that works with system APIs at all.
First off, I want to clarify that Linux is actually just as backwards-compatible as Windows. The only Windows APIs that are backwards-compatible are the operating system APIs - the lowest level ones, made by MS themselves. This is just as true for Linux. Linux kernel functions are absolutely backwards compatible - you can even find documentation in them explaining that certain flags or function arguments exist just to be more compatible with other similar APIs. Core libraries like X11 and Wayland also have very few breaking changes (besides Wayland's unstable APIs, which are work-in-progress and thus do have breaking changes).
What isn't backwards-compatible - on either system - is all the third-party libraries installed by the user. These libraries do get updated when new distro versions release. They can also get randomly updated on Windows. Check your installed programs and you'll probably have about 5 million versions of the Microsoft C++ or .NET runtimes - those are the kinds of libraries that can get random updates and break a program.
There's a very simple solution to this, though, and basically every game follows this - you just ship the libraries you need alongside your app. Basically any app you run today will have its own code and a bunch of libraries it needs to run correctly bundled with it. Languages like Rust, C++, C, and Go will compile those libraries into the final binary. C#/.NET will ship a bunch of .DLL files that it loads at runtime, but they're all at the correct/needed version for the app. These solutions just work regardless of OS - it's not a windows exclusive. Linux also has some dependency managers, which let an app say "I need this library at version X.X", or just ship those libraries with the app similar to .NET's DLL solution. Examples of these dependency managers are Flatpak and AppImage, and they're widely used already (I have programs installed from both on my machine right now! You can also go look at the statistics page for Flatpak/Flathub - it has thousands of apps and hundreds of millions of downloads).
From my understanding of what you described, it sounds like native Linux games just assume a bunch of libraries they need are already on the user's computer. This doesn't even make sense because the developer has no idea if that library is on the computer or not, and even if it is on there somewhere, it's *way* more likely to be the wrong version than the right one. (Also, this would still be problematic on both Linux and Windows.)
Thank you for taking the time to write such a detailed comment.
The OS (a distribution like Ubuntu) provides a set of software alongside the kernel. For example GTK, XWayland, Mesa, many different libraries, etc.
If a game uses some of these libraries and the distro maintainer deciedes to remove them (e.g. 32-Bit libs) then the game wont work anymore after the distro update. Or imagine the current Mesa major version causing problems in a certain game. Have fun downgrading these yourself and not breaking anything else.
Windows still provides decades-old UI frameworks and you can simply install an old DirectX version if necessary. They can do this because they own this software.
Simply shipping and static linking open source software in a closed source commercial program opens the gates to license hell. You seem very experienced, you should know that.
I'm not advocating windows. I mean this is a Linux gaming channel. But native games very often don't work and I've listed the reasons why. This is a 4 minute long video, it should be clear that it doesn't go into extreme detail. Yet the statements are true.
@@LowBudgetLinuxGaming (To preface, I also came from that same friend complaining.)
_"Simply shipping and static linking open source software in a closed source commercial program opens the gates to license hell."_
That very heavily depends on the license. Libraries that are GPL require whatever software uses it to also be GPL usually regardless of whether it is statically or dynamically linked, but ones that are LGPL only require derivatives of the library itself to be under LGPL and closed source commercial software can still use them. Specifically, the LGPL stipulates that if your commercial software statically links against an LGPL library, you also have to provide the application in an object format that allows the user to relink the library themselves, or a different fork or whatever else; and that if your commercial software already dynamically links against a packaged LGPL library you don't need to do that. This is the case of ffmpeg, used pretty much anywhere as soon as media processing is involved. In fact, on Windows, closed source software that relies on ffmpeg just ships the ffmpeg DLLs along with the application, which on Linux would be the equivalent of providing an appimage. All of that being said, there are also a lot more libraries that do not use the GPL, LGPL, Mozilla License 2.0 or other such restrictive licenses. Most Rust crates for example use either the MIT license, the Apache 2.0 license or a dual-licensing of both as that is the Rust language's own licensing model. (not legal advice)
All in all I agree with the misleading nature of the video. It may be 4 minutes long, but we still got our friend new to Linux and freshly unaware of these solutions and nuances end up thinking that native Linux games can end up getting broken by some random maintainer of a library far away in the dependency tree who decided to just make a breaking change, which as I said in a different comment is not possible even if the game were to be packaged on the distribution at hand due to the package managers' version management, and frankly, would be completely absurd.
First of all I would like to thank you for watching the video and writing comments. I love discussing Linux related topics :-)
The fact that native Linux games often have problems after a few distro upgrades is not a new finding. I noticed this again while making this video and several comments confirm this. If it's not the reason I mentioned, can you tell me what's causing the problem in the native games.
I have been working as a full-time software developer for over 10 years. Every time open source libraries have been involved, the licensing model has been an issue. It's not just about the license that a library uses, but also the licenses of the software that this library includes. This can quickly become an exponentially growing problem.
If the solution to the problem were as simple as making an AppImage or simply adding all the necessary libraries to the game, don't you think the developers of the games wouldn't have even thought of it themselves over the years?
Also keep in mind that commercial games are usually not installed with a packet manager.
The video is about how native Linux games have their problems, but Proton solves these problems. On Linux... How can this scare new users away? If you could scare off users so easily then Windows, with all its problems, wouldn't have any users for a long time.
_"I have been working as a full-time software developer for over 10 years"_
For context, I'm also a full-time software developer. Though it's been only over 2 years and for a relatively unrelated project to the problem at hand (since it's not a native client application), on the side, I've been doing native client application development for more years than that and have also had to deal with native Linux APIs like Xlib and Wayland, and have worked with BrightShard (the OP above) on common native projects.
Apologies in advance for the multiple comments, TH-cam's spam filter is just that bad.
_"Don't you think the developers of the games wouldn't have even thought of it themselves over the years"_
Yes, in fact they have. One example is osu lazer, the official next iteration of osu that is cross-platform. It ships ffmpeg dynamic libraries in its appimage, despite not being licensed under the LGPL and having a few closed source and commercial components for the game. There are also a lot of proprietary software with flatpaks, and a lot of them are widely known and used. Steam itself also has one.
Shouldn't Vulkan help fix most of this? Why are people still not using it in favor of DirectX?
because its harder to use and not available on xbox
@@kvdrr Well, Xbox needs to just GO I guess. Or update to have vulkan compatibility. It literally works better than OpenGL and on most devices too. DirectX afaik is microsoft only. So something doesn't add up.
I just realized your using the same cpu as me
But yours is a amd gpu and am on nvidia
Linux Native Metro Exodus can't even load on my PC. It's not because of the Wayland because I used X11
I tried on Arch, Fedora and Ubuntu. None of these worked. So I started playing the Windows version through Proton and everything worked well.
How is that posible native linux game have bad performance compare proton windows version
The native Linux games I tested in this video had better performance, but unfortunately they had other problems like missing features or that not every game was able to start on more recent distros.
@@LowBudgetLinuxGamingMetro Exodus was faster via Proton, as you pointed out yourself.
@op, there can be a few things that might be the reason. My guess would be the graphics API. The native Metro probably uses Vulkan. Vulkan is notoriously not the easiest to program for, and ignoring that rumor, it is as a matter of fact less popular and thus well known as DirectX (DX)
The Windows Version will most likely use DX12. If you use Proton, this will be translated to Vulkan. But it can very much be that they do a better job translating DX12 stuff to performant replacements in Vulkan than the game porting studio did.
will you nerds please hurry the fuck up we only got a year left on windows 10 and i want a SOLID linux distro. fingers crossed for steam os.
I USE ARCH, BTW
1:54 _"The reason why native Linux gaming sucks is because Linux distributions are not backwards-compatible [...]"_
I really do not think this is why native Linux gaming isn't quite there compared to Windows. This compatibility problem already has widely used solutions such as appimages, flatpaks, and the Steam Runtime in the case of Steam games. Statically linking libraries is also a possibility. With these solutions, it boils down to whether the Linux kernel APIs are up-to-date enough and then the other essential APIs like X11 for windowing, ALSA for audio and _maybe_ also libc if you don't use musl instead. These have a pretty solid API and having a breaking change on them would be very unheard of (it would also break the entire ecosystem).
That being said, the problems you've highlighted before that section seem completely unrelated:
- The first game crashing on Wayland is because you didn't have XWayland installed, otherwise it would've used that, but the game didn't anticipate that unfortunately.
- DLSS and XeSS upscaling lacking SDKs on Linux is an official Linux support problem, not a distribution compatibility problem.
Heck, even if we assume some games are integrated as a package on the right distribution, this argument doesn't make sense. Package managers explicitly have a mechanism to deal with version compatibility between packages, so you can't just have a dependency update with a breaking change unless that dependency badly manages its versioning or the game developers did not package the game properly. You'd get an entirely different problem like not being able to install the game if you don't have the correct versions and the package manager happens to not accept multiple coexisting versions of the same libraries, but at least you won't get a game crashing on you because some of its dependencies got updated and you didn't notice.
So frankly I don't understand where this argument comes from.
Valve's approach is still better in my opinion. They ship libraries with the game and add them to library lookup paths by setting LD_LIBRARY_PATH. You don't need a whole flatpak or appimage to do this.
dying light is one of the games that forcing proton is just better. the native port seems to be abandoned and has worse performance
2:29 i dont see any reason why an application cannot come with all the dependencies on linux, the same way as on windows. dependencies isnt much of an issue
on linux if a library turns out to be vulnerable, you just update the package and all apps that depend on it are now safe to use. on windows, you're screwed if app developers don't push an update.
@@kvdrr exactly
That's been my experience. I kept hearing people say that Linux was basically ready for gaming now, and it had been a few years since I looked at Steam on Linux. I'm wanting to switch over to Linux as my daily driver OS so it was a good time to revisit all of this. And ... gaming is still garbage on Linux. On top of the limited number of games from my Library that were playable, performance was rough and crashes frequent. Could I have spent some time to fix some things? Sure, maybe. But that's not how I want to spend my time. Gaming is definitely getting better under Linux, but I don't want to spend my time fighting with it.
I think you misunderstood the video a bit. Gaming on Linux is awesome. I also have a video comparing the performance between Windows and Linux and it was about the same.
The video is about the fact that native Linux games have their problems but Proton on Linux solves all these problems.
on Windows in ost cases the libs are packaged in the same directory as the software, on Linux, inmost cases the libs are shared between all the softwares, but, now, we have flatpaks that encapsulate all the libraries and the software itself on a "container" independent of the system libs, solving that problem, but in games, the old method of distribute software is used and flatpaks isn't a reality in that market, because of that, today, proton can be the workaround for the problems in Linux gaming until the developers/ressellers repackage that games in flatpaks.
Bitte hauen Sie später ab und schreiben Sie dann verärgerte Kommentare 😅
The problem is not backwards compatibility, the problem is that those games rely on ancient versions of these libraries that are no longer shipped by default with newer distributions. With Windows it's different, most third party libraries are supplied with the game so you don't have to worry about these. But you will find that some older games that use ancient versions of the Direct X API will also have problems with more modern versions of Windows. The reason why this happens on Linux is because you are in an open source environment where every piece of software is meant to be recompiled for your system. The reason why you don't normally have to do this is because package managers ship versions of this software that are compatible with the libraries already provided. And because this is a common and well known problem in Linux, containerization using software such as Flatpaks or even docker is starting to gain popularity, specially among proprietary software. With these, you can ship software with all the precompiled libraries, and make it work in a sandboxed environment without having to worry about libraries being outdated. The solution is simple, ship your games using a container. Problem solved. But because gaming on Linux is just catching up right now, it's going to take a while and older games not developed by Valve are going to run with these issues.
Linux in general has a MAJOR problem.....its never anyones fucking fault. Ppl will say its not the problem of the kernel its the problem of the window managers, window managers devs MIGHT say that its something etc....Linux devs and community in general really like shifting blames onto one another and barely actually fixing the problem
proton is garbage and emulation. native shows that linux is taken seriously.