upvote
I have stopped playing native ports and just prefer Proton when I have the choice. Many devs using Unity & co. just tick the "export to Linux" option and never try the build, which is often much slower or bug ridden.

I was playing Project: Gorgon recently, I was about to refund because it ran terribly on my machine (despite the low end graphics), when I noticed it was using the native build, switched to Proton and got a 200% FPS boost.

As long as I can play on Linux, I don't care what translation layer it goes through.

reply
I'd argue that "native" is much more of a state of mind than a clear delineation anyways.

Among many game developer studios, the Steamdeck is increasingly becoming the defacto low-spec hardware target. Running their game on a Steamdeck becomes a core part of the QA process, because there's a few million Steamdecks out there actively playing games, and if your game runs on a Steamdeck you basically know it'll also run on a very wide range of hardware configs.

So while the game might be targeting a different API than the standard ones exposed on Linux machines, a lot of games now are directly designing their software to make sure they run well on a Linux handheld. Meanwhile, Linux is adopting more and more features to better support this non-standard API set.

At a certain point I think we can just call Proton/WINE a 'native' API for gaming on Linux, and say that games developed with Proton/WINE in mind are native games.

Perhaps we're not at that point yet, but we might be there soon.

reply
Disagree. The word "native" in a software execution context has a very specific meaning—it means that the software is running on the target hardware with no emulation, translation layer or modification by any middleware. Games running through Proton/WINE will never be native, by definition.
reply
I'm not super sold on Wine/Proton being the solution to Linux gaming as it still leaves Microsoft in control of the future, but the distinction is quite murky. A lot of "native" ports also use translation layers internally to various degrees.
reply
x86 bytecode isn't the native instruction set on any real hardware you're running games on either, just one of the lowest-level publicly exposed interfaces.
reply
if it's the lowest level available, then it's as close to "native" as we can get, so therefore it has to qualify, if we want to consider anything at all to be running "natively"
reply
deleted
reply
Isn’t that moving the goalposts? If an API isn’t exposed for native code then maybe we should just accept that we can’t write native code anymore instead of stretching the definition.
reply
From that point of view, native software effectively does not exist, and was long gone before the Linux project even started.
reply
And exactly why Apple's push for Mac gaming (which still puts native ports as the ultimate goal and treats things like GPTK, despite having made it, only as "ways for developers to preview how the port would end up" and not intended for general consumer use) is never going to work, no matter how much cash they throw at it.
reply
EA's horrible launcher comes to mind.
reply
Yeah, PC games are like console cartridges. You plug them into a compatible slot and they work.
reply
What? Look, things have gotten much better, but pc gaming, esp via proton is no where near as seamless as playing on console.

In fact, I went with console + linux laptop for ages simply because that combo excelled at their respective roles, were cheaper together than a gaming pc, and it 'just worked'.

I did eventually cave and build another gaming pc, but that was after I acknowledged that I could push out on the price / perf curve to something less 'optimal' (and it let me play with local LLMs)

reply
Not the ideal path though - that's still source ports.
reply
[dead]
reply