[p1necone]

Yeah that's been my experience with native Linux builds too. Most of them were created before Proton etc got good, and haven't necessarily been maintained, whereas running the Windows version through Proton generally just works.

Unfortunately it seems supporting Linux natively is pretty quickly moving target, especially when GPUs etc are changing all the time. A lot of compatibility-munging work goes on behind the scenes on the Windows side from MS and driver developers (plus MS prioritizing backwards compat for software pretty heavily), and the same sort of thing now has a single target for peoples efforts in Proton.

It's less elegant perhaps than actual native Linux builds, but probably much more likely to work consistently.

[GCUMstlyHarmls]

Sometimes you see developers posting on /r/linux_gaming and generally the consensus from the community is mostly "just make sure proton works" which is pretty telling.

It's sort of a philosophical bummer as an old head to see that native compatibility, or maybe more accurately, native mindshare, being discarded even by a relatively evangelical crowd but,

- as a Linux Gamer, I totally get it - proton versions just work, linux versions probably did work at some point, on some machines.

- as a Developer, I totally get it - target windows cause that's 97% of your installs, target proton cause that's the rest of your market and you can probably target proton "for free". Focus on making a great game not glibc issues.

I mostly worry about what happens when Gabe retires and Valve pivots to the long squeeze. Don't think proton fits in that world view, but I also don't know how much work Proton needs in the future vs the initial hill climb and proof-of-success. I guess we'll get DX13 at some point, but maybe I'll just retire from new games and just keep playing Factorio until I die (which, incidentally does have a fantastic native version, but Wube is an extreme outlier.)

[bitmasher9]

1. I think targeting compatibility is 99% as good as targeting native.

2. You’re discarding the shifting software landscape. Steam OS and Linux are trending towards higher PC gaming market share. macOS has proven you don’t need much market share to force widespread (but not universal) compatibility.

3. I don’t see the value in a purist attitude around Linux gaming. The whole point of video games is entertainment. I’m much less concerned with if my video game is directly calling open source libraries then if my {serious software} is directly calling open source libraries.

[ehnto]

On point 3, I guess my views are different because my {serious software} is usually work, and if it stops working that's kind of a B2B problem and part of doing enterprise. It's just business as they say.

Gaming is much more meaningful to me as a form of story and experience, and it is important to me that games keep working and stay as open and fair as possible. In the same way it is important I can continue to read books, listen to music or watch movies I care about.

[ajvs]

> Unfortunately it seems supporting Linux natively is pretty quickly moving target

With the container-based approach of the Steam Linux Runtime this should no longer be a problem. Games can just target a particular version and Steam will be able to run it forevermore.

[ehnto]

I would hope Vulkan also does a lot of work here for linux native builds but I must admit I am only now starting my journey into that space.

[59nadir]

A lot of those Linux native builds will have been using Vulkan.

Parity between DX12 and Vulkan is pretty high and all around I trust the vkd3d[0] layer to be more robust than almost anything else in this process since they're such similar APIs.

The truth is that it's just a whole lot harder to make a game for Linux APIs and (even) base libraries than it is to make it for Windows, because you can't count on anything being there, let alone being a stable version.

Personally I don't see a future where Linux continues being as it is (a culture of shared libraries even when it doesn't make sense, no standard way of doing the basics, etc.) and we don't use translation layers.

We'll either have to translate via abstraction layers (or still be allowed to translate Win32 calls) to all of the nasty combination of libraries that can exist or we'll have to fix Linux and its culture. The second version is the only one where we get new games for Linux that work as well as they should. The first one undeniably works and is sort of fine, but a bit sad.

0 - vkd3d is the layer that specifically translates D3D12 to Vulkan, as opposed to vkdx which is for lower D3D versions.

[account42]

It's not really harder to make a good native Linux port that will keep working, it's just not something most game developers have much experience with.

[pluralmonad]

I have a slightly different view. The former scenario is essentially having our cake and eating it too. I'd rather not "fix" Linux culture.

[59nadir]

Too late for an edit now, but `vkdx` in the note here is supposed to say `dxvk`.