The goal has to be to make native Linux attractive, so that they actually bother to create native executables, using Vulkan and co.
Until then it is no different from playing arcade games with MAME on Linux.
The goal has to be to make native Linux attractive, so that they actually bother to create native executables, using Vulkan and co.
Until then it is no different from playing arcade games with MAME on Linux.
There are many older games I can't install on Linux anymore, because they used an older SDL1 or some particular X11 version or some GPU driver that's no longer available for the current kernel.
The exact same game, Windows version, can be installed and runs flawlessly on both Linux and Windows.
So, native Vulkan executables? Sure, if they can continue to run in 20 years.
That’s one of the most successful computer projects I’ve heard of.
I don’t even know what you’re arguing now.
Your point?
And they run fine.
You are not reinventing the wheel. Just maintain the damn thing and keep it running as is. As Linus once said "If there's a bug that people rely on, it's not a bug, it's a feature.".
This is a similar idea to flatpak/snap etc.
For them DirectX and Win32 is what matters, if folks go out of their way to run on Proton, that is Valve's problem.
There's outliers, it'd be fair to say EA don't give a damn. But a lot do and you can't handwave away Microsoft and Sony as small fish either.
I don't think so. I rather do believe that many game developers would actually love to give a more native approach for writing GNU/Linux games a try (to make this point more plausible: game developers are very used to game-console-native SDKs).
But what these game developers really demand is a very stable user-space API for everything that is necessary for writing games, which will work reliably on basically every GNU/Linux distribution, and will be supported for at least 20 years.
Literally half the gaming/hardware focused channels I watch have run at least one, if not several Linux Gaming videos and tests this past year... mostly in the past 4 months and mostly praising the state of Linux gaming. It's not going away.
I don't think I'd be willing to place bets on Linux dying any time soon.
And studios definitely check out their games running on Steam Decks via Proton now, so that's good.
That said, as long as windows is the bigger more profitable market I wouldnt expect a switch, unless the dev tooling situation becomes dramatically better on linux
They are more likely to move to PlayStation and Switch than SteamDeck, the amount of sales already show that.
Sure, the platform is enshittified spyware, but that only impacts the game devs on their work machines (which are probably locked down to protect secret IP anyway). Microsoft has basically lost control over their own platform at this point. The game studios have been refusing to migrate to new APIs until after they're working well in Wine.
If the rest of us can run something decent at home, that's a > 99% solution to the problem.
Put another way, for a long time, you needed to buy an SGI workstation or whatever to make assets for PC games. That didn't hold the DOS ecosystem back.
As for the ABI:
The Linux kernel has started adding syscalls to enable native-like execution of Windows binaries, and game devs are testing with Linux at launch. In the worst case, these are only used by Wine. In the best case, some good ideas from the Windows kernel will be exposed to regular Linux user-land.
I don't see how it really matters if the binaries are targeting libc, musl, or an opensource win32 / win64 layer. It's free software regardless. End-users are getting better backward compatibility under Linux than Microsoft is supporting under Windows. That one victory goes a long way towards winning the entire war.
On top of that, Linux is starting to show better framerates than Windows in the same hardware. It's not 100% of the time, but it's enough that you should run the game in both places if you really care to get that extra few percent out of the hardware.
They still aren't Linux games.
I would say it's a lot different, since it's an API implementation, not hardware emulation.