Native Linux Build

[logan2611]

With the rise in popularity of Linux as a gaming OS, and the upcoming release of the Steam Deck, I feel that a native Linux build of s&box should be discussed.

Here is a short and incomplete list of reasons why native builds are good:

• Less overhead (better performance)*
• A lot of developers use Linux
• Easier to debug
• Linux users are more likely to buy your game

Linux users are still a small minority and in the game's current state Linux support is not going to be very high on Facepunch's to-do list. However, it's not fair to just toss the idea out entirely.

*Untested, but I can't be bothered to spend the 2 or so hours installing Windows 10 just to test a single game's performance

[xDShot]

Seeming that there's no way to attach debugger from vscode to running game instance from proton, so it's also good reason to have native port.

[x1unix]

Theoretically, you can start vscode-server on wine (proton) side and connect from VSCode application to it.

[logan2611]

Yesterday I found out that Facepunch removed the Vulkan backend from s&box. I haven't gotten a definitive answer as to why, but according to the Discord it's because the Vulkan backend isn't implemented very well in Source 2 and they don't want to maintain 2 separate graphics APIs, so they chose DX11. Thankfully this project exists and is actively used by Valve themselves so that games can natively render Vulkan while still using DirectX.

[logan2611]

Replicating changes and testing them to work on multiple renderer backends isn't exactly the easiest thing or best thing to spend time doing when you're rapidly adding / modifying features to an engine.

Thanks for repeating that.

Not really worth their time when 99% of their players are going to simply be on Windows, so targeting only DX11 makes perfect sense.

For this reason alone, no it doesn't really. I already gave an actual reason as to why, and then proposed a workaround for a native Linux build while barely even touching the graphics backend.

Also I'd just like to reiterate that not only is Linux adoption increasing already (even according to the somewhat flawed Steam HW/SW survey), but also the Steam Deck will likely explode that number to far higher than the 1% that the Steam HW survey claims.

[Rohansi]

1% of Steam users being Linux users does sound too high

[ghost]

1% of Steam users being Linux users does sound too high

It seems small relatively, but that's 1.2 million steam users right there, and will only increase after the new Proton fixes and the Steam Deck

[togetherwithasteria]

1% of Steam users being Linux users does sound too high

It seems small relatively, but that's 1.2 million steam users right there, and will only increase after the new Proton fixes and the Steam Deck

Agreed with that. And hey, I just switched to Linux few weeks back.

[Newbytee]

@Rohansi 1% of Steam users being Linux users does sound too high

It's what Steam's own stats say:

See for yourself: https://store.steampowered.com/hwsurvey

[mindinsomnia]

With the rise in popularity of Linux as a gaming OS, and the upcoming release of the Steam Deck, I feel that a native Linux build of s&box should be discussed.

Here is a short and incomplete list of reasons why native builds are good:

* Less overhead (better performance)*

* A lot of developers use Linux

* Easier to debug

* Linux users are more likely to buy your game

Linux users are still a small minority and in the game's current state Linux support is not going to be very high on Facepunch's to-do list. However, it's not fair to just toss the idea out entirely.

*Untested, but I can't be bothered to spend the 2 or so hours installing Windows 10 just to test a single game's performance

Lots of advantages of a native build over allowing a game to run via Proton.

• Stability: While Valve does their best to avoid such issues, Proton is constantly changing, trying to hit a moving target of matching Windows for compatibility. This can and has resulted in regressions with some games broken by updates that fixed other games. Not only that, but there are multiple versions of Proton out there in the wild. There are also commonly used community versions, such as Proton GE. Different users may use different versions of Proton as their default depending on what normally works best for them. All this results in lots of uncertainty over how exactly your game may run for each user, and even possibility for your game to be broken by a Proton update. If you want more certainty over how your game will run? Compile it as a native Linux application, include your own dependencies. Then there's a lot less wiggle room for uncertain outcomes.
• Performance: As stated already, a well optimised piece of Linux software will run more smoothly than a piece of Windows software running via a compatibility layer.
• Debugging: Already stated but worth repeating, it is definitely easier to debug Linux software, compiled on Linux, running on Linux, than to debug Windows software, compiled on Windows, running on Linux, where the source of your bugs might be from your game, or might be from Proton.
• Sales: Steam offers the option to configure the store to only display games that are compatible with operating systems if your choice. Many Linux gamers may have such options enabled, and thus may never see even a perfectly compatible Proton game as available on the store. Other Linux gamers may be more hesitant to buy a Windows-only game, knowing that it means the game developers have no intention to support officially Linux, or may only buy such games when on sale. Not only that, but some websites such as http://www.gamingonlinux.com often promote native Linux titles, which could result in a boost of sales.

[Rohansi]

For any kind of proper discussion here you'd need to consider all the disadvantages too, from our point of view.

The stability argument is debatable. Proton is more than just a compatibility layer for running Windows programs on Linux. It's also abstracting over Linux and all it's distro-specific (or even user-specific) quirks. Without Proton we would be responsible for all of that - and none of us run Linux.

[garrynewman]

No plans to support Linux natively. While the deck is good to support - I've tested it and it works great. Could it run better if it was native and using vulkan? Probably. But it would also run better if you format it and install Windows on it too.

Any support for Linux outside of it running on the deck is incidental, it isn't supported officially.

Edit:

For the sake of clarity, I wasn't suggesting that a windows native version would run better than a native Linux version. I was suggesting that installing Windows on the deck and running it natively might perform better than running it through Proton. Personally I believe the benefits would be minimal - The deck is powerful enough that you're always going to be over 60fps in either scenario.

Proton is a good thing, it outsources compatibility to the Valve Linux guys who care about this stuff, improving it improves every games support for Linux. It's the silver bullet for Linux gaming - I don't really understand the hostility towards developers making sure their games work with it instead of making what would otherwise be a sloppy and badly supported port. It's win win for everyone.

[bucklingspring]

I respect your opinion but I hope you reconsider eventually. The advantages discussed above are solid.

[ZarathustraDK]

I can get not wanting to maintain a native port alongside the windows-version for the extra work it entails, I don't understand the choice to go with DX11 instead of Vulkan though. Even if there's some technical caveats to it the payoff in potential platform-independence and performance seems a strange thing to eschew, Doom 2016 and Doom Eternal are good examples of this.

"But it would also run better if you format it and install Windows on it too." - Jeez...

[xDShot]

It runs great in proton, yes. But what about this?

I could try somehow install Win version of vscode and try running from proton prefix, but it's huge hack (if there's any luck running this). Currently this is only thing preventing me start coding for the game and I don't want to be forced to move to win10/11 platform.

[VortexAcherontic]

Well since SteamOS runs off Arch Linux and Arch Linux does not tend to ship with custom compiled libraries and is pretty close to upstream software I won't expect a game running well on a Steam Deck using SteamOS to not run well on any other major distribution.

Actually I feel more comfortable if devs would target a rolling release rather than a point release. Because of the "Frankenstein-Software" point releases tend to ship and build up over time.

You know like:

• some running some version of a Kernel but with back-ported drivers from more recent kernels. While other point releases do not include them or include others instead.
• Some library with back-ported functionality other might not have.
• The other way around: disabled features in some library because something does not work right with the somewhat custom code base point release run is one form or another.
• Some patches to some software made specifically for this particular point release which on others with a different code base might not require or might require other patches.

Running of a clean up-to-date code base will most likely cause a lot less compatibility issues. With Arch Linux becoming the new standard to develop software towards it and for I don't see this as a huge issue if someone would focus on SteamDeck compatibility.
As long as they do not start to hard code "lib" and "lib32" too look up libraries while on other distros this might be "lib" and "lib64" instead. Which actually was the only issue I ever had with software compiled on and towards Arch Linux on a none Arch based distro

[Weirdo1312]

No plans to support Linux natively. While the deck is good to support - I've tested it and it works great. Could it run better if it was native and using vulkan? Probably. But it would also run better if you format it and install Windows on it too.

Any support for Linux outside of it running on the deck is incidental, it isn't supported officially.

Windows UI isn't optimized for handheld devices, the UX is going to be an abomination for a handheld device
Installing windows isn't going to make everything better, you're also putting all that battery and performance optimization for dexk into the trash by installing windows
And that's IF there is a windows driver available at day one

[lordkitsuna]

as a full time linux (arch btw) user that no longer has any windows machines in my home. hard disagree, native simply is not worth a devs time for linux. full stop. performance isn't even a good argument we have multiple games where the linux native actually performs worse than using proton with the windows build. even when the native does manage to pull ahead its usually damn close DXVK is pretty damn near native windows performance in most titles. i have personally tested this at least with my library before making the no windows transition.

the advocacy should be please target libraries fully supported by proton. this gives linux high quality compatibility without wasting the developers time maintaining and debugging a different build for a tiny fraction of their users. they only have to properly build against windows and proton handles any issues from there. never understand this obsession with native it really holds linux back. running is running native or otherwise. also the sales arguments are laughable there is zero proof of this and even if 50% of linux gamers bought any and all native titles many games would hardly notice

[VortexAcherontic]

I somewhat agree but also disagree here 😄

Yes the obsession with native or nothing is sometimes hard too understand for me too.
And I have a variety of games running better with Proton + DXVK rather than the native port.
But those are often because of the devs not putting any or very low effort into it.
I agree looking at the numbers and even if 50% of the 1.2 million Linux users would buy the game, it is hard to tell your finance officer this was worth it.

But also you are doing a misconception here.
Often game devlopers are used to Windows and to develop towards the WIndows ecosystem and using tool build, optimized and probably build on Windows for Windows.
To over come this pipeline and to support a platform which is completely out of the loop is in fact hard and prone to errors.
You have game engines optimized towards Direct X, relying on Dot.Net, Windows Media Foundation eg.
If you now suddenly add a platform where neither of those things are available you need to find a replacement. But not only that you also wouldn't start to rebuild your windows code too.
So you end up with two code bases, with two different sets of tools and frameworks to maintain and you slow down the overall development process unless you make one of those platforms a low priority to receive updates later or when ever there is time for it.

But, if you would use the same tech on Windows as you would on Linux the entire thing would be a lot different.
For example, why not use Vulkan on both platforms, Windows and Linux? Why not using SDL2 on both platforms? No duplicate code base to maintain, tools build and optimized towards both platforms. If this would be the case the performance, work and effort to support both Windows and Linux would be a lot less of an issue.

The ports you talk abut are of games coming from a Windows ecosystem and someone somehow strapped Linux support into it so that it at least runs ... well in most scenarios.

I agree having an existing pipeline to replace with a software stack like mentioned above is also pain. But would benefit in the long run. Both the consumer and the developers.

Proton on the other hand is a very fine tool for the meantime. Such a transition will take time and probably not all developers studios will and can take this effort to build a new pipeline with both platforms in mind.
So I agree with both: Target Proton is god enough for me, but for the sake of your own freedom, peace of mind and being future proofed it might be worth to start building a pipeline which does support both platforms with the lowest extra costs possible. Eg switching entirely to cross platform frameworks and tools and not using tech A on platform A and tech B on platform B the tools are there you just need to adopt them.

I know this easier said as done I am aware of this and maybe I am a bit too over optimistic but we'll see I guess 😃

[nuggs]

native simply is not worth a devs time for linux. full stop. performance isn't even a good argument we have multiple games where the linux native actually performs worse than using proton with the windows build.

For the most part, if you write cross-platform code and use cross-platform libraries it's really not that hard to maintain(I used to write GNU/Linux only software and porting to Windows was sometimes a pain). If you go into development with the mindset that you're never going to release for a different system and tie yourself down to that system because of that, that's on you. That's where most of the "it's not worth it to port it to GNU/Linux" comes from. It's because the developer made poor decisions when they initially started making their game.

As for games performing poorly or worse than builds using Proton, that's on the developer and has nothing to do GNU/Linux

[julienbenjamin]

as a full time linux (arch btw) user that no longer has any windows machines in my home. hard disagree, native simply is not worth a devs time for linux. full stop.

Actually, it is @VortexAcherontic. The problem is not that nobody wants to program for Linux but rather do not know how to develop cross-platform compatible programs.

Game devs and a significant part of all other devs do not know anything about system programming, contrary to the past machines, where you had to tailor your game for the machine at hand - the only documentations they know are the game engine and Microsoft ones, or the devkits' one if you want to add one. Even on Windows, you can see how bad PC ports are most of the time compared their consoles counterparts (I know there are other factors at play in this example but still).

Say in other words, the "Linux vs. Windows" issue disagreement here is mostly due to the fact that devs do not know how to program for different platforms, so cross-platforming is already a problem. This is like for a sysadmin "do you know networking or do you know Cisco?" - at some point when you are buried too deep in your own closed ecosystem, even if you do not like it, you are bound to its rules and if you do not know what you are really doing. This explains the bad Linux native build and the bad PC ports from console, BTW.

The funny (or not) part is that programming and standards comes from the Unix world ; it is ironic that video games, one of the most dynamic real-time performance of the software industry is so clueless at how high-performance computing techniques work because they do not want to bother about fundamental of their field. I mean there is a reason why the vast majority of supercomputers is running Linux ; on the other side, the video games industry which aims to achieve a whole other level of responsiveness, real-time graphics, etc. embraces a total different pattern, leaving the "how it works under the hood" necessary part to everyone that wants to tackle it such as hardware manufacturers, Microsoft, etc. No wonder why there are problems in the short, middle and long term.

TL;DR: Most devs do not know how to program properly and are happy to outsource it to anyone who asks such as Microsoft instead of relying on solutions that were the basics not so long ago and would ensure less problems at any point in the future.

[FruityWelsh]

Personally, it would seem like if engineering effort should be directed anywhere, it should be moving away from dx11 to vulkan. Since:

1. it reduces the number of difference between platforms (Games on Windows, steam deck, and vulkan compatible os like desktop linux would all be using the same API with less overhead to trouble shoot (such as dxvk).
2. It is more extensible being an opensource project meaning if a new feature or backend improvement is needed it can be made, tested, and upstreamed.

Targeting the windows APIs (and thus proton) for everything else has less overhead and performance penalties than the graphics library, though as someone else stated it will be more work debugging non-windows deployments such as the steamdeck.

[Trojaner]

https://www.reddit.com/r/linux_gaming/comments/p3fahv/vote_for_native_linux_builds_of_sbox_facepunchs/

This is just pathetic

[Rohansi]

None of us run Linux, we're all Windows and some also macOS. This might impact your voting outcome.