Unity announce expanded support for Steam, Native Linux, Steam Deck and Steam Machine

Quoting: CatKiller=
Of course, back then, OpenGL support was about the same on Windows, Mac and Linux, so you could avoid duplication of work. Vulkan support on Windows isn't that great, and it's non-existent on Mac, so there'll be more platform-specific duplication of work this time around.

true, except that the apis are similiar because you cant change much once you get so close to the hardware

Linux native builds issues:
1) Distro/library fragmentation makes testing impossible
2) GPU drivers lagged behind Windows
3) Tiny market share, low QA investment
4) 32-bit and glibc compatibility issues
5) Anti-cheat and middleware lacking Linux support
6) Proton killed native port investment
7) Developer tooling gaps or bugs during conversion

Unity SDK support should help with items 1) 4) and 7). It won't be a silver bullet but will help a huge amount to standardize the output of the builds. If the native builds are more similar across games, it will be easy to support on each distro.

They are targeting SteamOS too which narrows the scope and makes it easier

Quoting: Stella

But I think we can do better with a native solution.

I hard disagree with this statement. Pretty much all existing Linux games suffer from various problems ranging from complete inplayability over control and gameplay/visual issues as well as crashes. Running games over Proton is vastly preferable to Native most of the time because the Windows API is much more stable than the Linux API. I myself have had so many issues with native ports that the Proton versions never have, that I've given up on them completely

You are completely right about the historical mess of native ports, but the "unstable Linux API" (or rather, [ABI](https://en.wikipedia.org/wiki/Application_binary_interface)) argument is based on an outdated architecture. Twenty-five to ten years ago, the ecosystem tried and failed to unify around the "[Linux Standard Base](https://en.wikipedia.org/wiki/Linux_Standard_Base)," which never actually provided a stable target for developers as it shifted goalposts continually. The Linux kernel itself has always been fiercely stable (adhering to the strict "we never break userspace" rule from Linus Torvalds himself), but what broke games in the past was the chaos of fragmented userspace dependencies, such as the glibc mess with conflicting "GNU-isms" across versions, and competing multimedia servers across different distributions.

Today, modern native Linux gaming bypasses that problem entirely through a completely new approach. First, the Steam Linux Runtime ensures games no longer rely on your host operating system's libraries. Instead, they run inside a frozen, containerized environment, completely bypassing the software rot that used to plague Linux ports. Second, hardware translation has finally been standardized. The universal adoption of PipeWire has permanently fixed the decade-long multimedia nightmare, elegantly replacing the deeply fragmented ALSA (ugh), PulseAudio, and JACK stacks with a single, unified audio and video pipeline. Combined with the newly stable SDL3, even older native games are retroactively forced to play nicely with modern Wayland desktop environments without the original developer having to update a single line of code. Proton/Wine is an incredible tool, but a properly packaged native game running within this modern architecture is now just as stable as a Windows binary, with zero translation overhead.

Quoting: GustyGhostI've been playing Linux native games (Unity, no less) that I had bought ten years ago without any issue. What is there left to improve?

i think the devs had to do somethings manually because the engine didnt fully support linux, or if it did the add'ons didnt, so there is that, maybe they can do something about that?

Quoting: PyronickProton/Wine is an incredible tool, but a properly packaged native game running within this modern architecture is now just as stable as a Windows binary, with zero translation overhead.

i saw this movie before, we dont have an great track record of backward compatibility and we cant know if its fixed now, we have to wait 10 years from now and if the things made now still work, that means we have backward compatibility... for things made years ago, but current stuff might still have issues, as new libraries are used that may not have the same track record.

in any case if wine can be stable then there is some stable basis somewhere, until it doesnt because any distro can break stuff on purpose, but the ones who do would be punished by the lack of users... i mean everyone loves snaps right?

in any case, even if an game work, the mods for it may not work, if an mod rely on changing something on a binary to work, and the linux version has an different binary because its native, we cant expet this mod to work unless we run the windows version of the game on wine insted of native, so yeah, wine/proton will still be used even in a future where all the games support linux natively.

anyway, do we still need an audio interface for professional usage? or pipewire does the job?

Quoting: Stella

But I think we can do better with a native solution.

Pretty much all existing Linux games suffer from various problems ranging from complete inplayability over control and gameplay/visual issues as well as crashes.

I think we play very different games.

Quoting: Stella

But I think we can do better with a native solution.

I hard disagree with this statement. Pretty much all existing Linux games suffer from various problems ranging from complete inplayability over control and gameplay/visual issues as well as crashes. Running games over Proton is vastly preferable to Native most of the time because the Windows API is much more stable than the Linux API. I myself have had so many issues with native ports that the Proton versions never have, that I've given up on them completely

In the end it's all a matter of support.
The fact that Proton works better is not just because of Windows API being stable, it's because Valve and the community are doing the heavy work of maintaining Proton and related programs so it keeps working well across distros and evolving versions of the ecosystem.
If Unity and game developers are being serious in supporting native Linux, they'll need to commit the same way as Valve does with Proton.

Quoting: elmapuli saw this movie before, we dont have an great track record of backward compatibility and we cant know if its fixed now, we have to wait 10 years from now and if the things made now still work, that means we have backward compatibility... for things made years ago, but current stuff might still have issues, as new libraries are used that may not have the same track record.

in any case if wine can be stable then there is some stable basis somewhere, until it doesnt because any distro can break stuff on purpose, but the ones who do would be punished by the lack of users... i mean everyone loves snaps right?

in any case, even if an game work, the mods for it may not work, if an mod rely on changing something on a binary to work, and the linux version has an different binary because its native, we cant expet this mod to work unless we run the windows version of the game on wine insted of native, so yeah, wine/proton will still be used even in a future where all the games support linux natively.

The backward compatibility issue for native Linux software has largely been solved, but not just by the modern kernel architecture. While it's true that the kernel handling DRM/KMS and memory management (instead of X11) created a vastly more stable and secure hardware baseline, older Linux software usually broke due to user-space library rot (e.g., missing outdated versions of glibc or libssl).

The real solution we have today is containerization and modern dependency handling. Technologies like Flatpak and the Steam Linux Runtime solve this by running applications in isolated environments that provide the exact legacy libraries they expect, preventing host system updates from breaking them. Furthermore, the ecosystem now heavily utilizes translation layers, shim libraries, and wrappers to seamlessly route deprecated API calls through modern, performant backends. For example, Xwayland translates legacy X11 calls for Wayland compositors, PipeWire provides drop-in shims for legacy PulseAudio/JACK apps, and tools like Zink or DXVK translate older OpenGL/Direct3D instructions into Vulkan. Add in user-space standardizations like SDL3, Wayland, and PipeWire, and the software stack is more robust than ever.

You are entirely right about mods, though. Because memory hooks and DLL injectors are built to target Windows binaries, highly modded games often run better using the Windows version through Proton rather than the native Linux port.

Quoting: elmapulanyway, do we still need an audio interface for professional usage? or pipewire does the job?

Regarding your audio question: PipeWire absolutely handles professional, low-latency routing (it natively implements the JACK API). However, it is a software routing daemon. You still need a physical audio interface for hardware inputs like XLR microphones or instruments.