Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
News of the day! This is the way! ...and will spread word. Now into waiting towards the full game with native Linux support
Hmm, Steam Deck seems to pick Linux runtime by default now and the Linux version is crashing on Steam Deck, but when I force it to run Proton Experimental from Steam Play settings, it works fine. For some games, Proton plays Windows games better than Linux builds.
There is no point to do Linux build if it's not as much tested as Windows build, and people should stop asking for Linux builds, Steam Deck automatically plays all Windows games with Proton and on desktop, everybody can force it to run with Proton too.
But there are other problems on Steam Deck too, one of which seems to be general problem with gamepads, menus doesn't work, luckily Steam Deck has option to use "Gamepad with Mouse Trackpad" controller layout, I only had to change it, so that clicking on right trackpad would make mouse left-click.
On desktop, I was even able to get it working with Stadia controller, I just had to enable Steam Input from Controller settings for this game (on Steam Deck, I think it's enabled by default). But again, menus didn't work and the turning rate for d-pad and left joystick feel different.
I tried to edit the controller profile for Xbox controller, so I could make right joystick to act like mouse, but it seems like the game somehow totally ignores these, even when Steam Input is enabled.
Also, some texts are way too small on Steam Deck, but fine on large monitor.
Most definitely there is a point on doing a native Linux build.
Well, of course a port is one thing - the actual support is another. Some particular game might for example - get an update that does not take some Linux aspect into account - thus suddenly breaking the "deal". Native Linux port usually brings an official recognition (support) with it.
We'd prefer an actual game support on Linux in great numbers. One might purchase a game - but run into a trouble - having the developers replying to a support ticket with something like "sorry, but your system is not supported" is a harsh possibility.
Proton is brilliant BUT if the developers know how to work on a native Linux build, that has ALL functionality - then that's technically (and in principal) even better. There is always the maintenance requirement, see.
That all said - Proton can serve a native-like experience at best! Linux native ports are to become a de facto when the Linux adoption increases all the more.
Thank you GeneRally 2 developers - and please keep up with the plan on a NATIVE Linux port (also would absolutely love to hear the current situation)
Same way like some code can be added to Windows version, which could be unhandled by Proton, the same way some code can be added to Linux version, which only works on your Linux machine with odd distro.
AppImage makes combatibility slightly better between Linux versions, yet I have seen games built on latest Linux, not working on any of the older ones (I think it was because newer G++ library that the new LTS came with). So, the solution is to make a Linux build on oldest Linux version anyone has, which can result in worse performance.
Instead on Linux build, that works only on specific Linux version that one developer had, developers could make their Windows build as compatible as possible with Proton, like supporting Vulkan and using open-source codecs for media files.
Kind of pointless to have Linux version for one specific Linux version, when most of Linux gamers on Steam are on another (Steam Deck), which could be using also different libraries.
Oh no, not pointless at all - just target the Steam Runtime and any distro that supports steam (most of them) will have no problem.
A lot of people don't know that Valve has their own Steam Runtime for Linux that one can use to load up whatever specific set of dependencies the game needs. Because of that, many native Linux games on Steam don't even use most of your system libraries.
So Steam has its own runtime that it uses for most games and it's basically shipping a copy of every needed dependency with the RUNTIME, avoiding the fragmentation the same way flatpak and snap does.
The reason they do this is precisely to avoid the fragmentation problem.
AppImages are sadly limited to xorg since the developer of AppImages is against Wayland, even though most used distros are switching to Wayland. There is however a tool called appimage-builder, that bundles all the required libraries (including glibc and libstdc++) with the app so that you can run it on a Linux distro which may be older or newer than the machine you compiled, but for games rather indeed devs should rather use the Steam Runtime Environment & for programs aim for flatpak, generic builds or snaps.
The diffrerent distros then - Ubuntu LTS? Ubuntu latest? Fedora?
Arch Linux based? Steam Deck testing?
—- Well, again, just test against the Steam Runtime, which will get all these cases. For usability and ergonomics though, it may be worth testing on a Steam Deck too, but just to see if it will run, the runtime is sufficient!
Indeed just target the Steam Runtime and any distro that supports Steam (most of them top tier and pro distros) will have no problem.
You can bundle glibc. In fact, things like snaps bundle the entire kernel into something that runs on any Linux distro.
It's possible to bundle the kernel as a snap, but you only need one of those. Applications bundled as snaps do not need to provide their own kernel. Snaps aren't VMs; they run on top of the host kernel.
It's just that, if you bundle certain libraries that have security vulnerabilities, and they don't get updated because they are in the bundle... Obviously, there are probably Windows games/programs that are 10x more insecure, because this is what Windows programs like to do. But we don't do that here :)
To many Linuxers now Wine/Proton is native. It's not an emulator, it's an open source reimplementation of what makes Windows programs run. If game devs aim for Proton, rather than for Windows, that's very fine because if Windows makes an update that breaks that game, it will still continue to work on Wine..