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.
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.
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.
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.
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"
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.
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.