Comment by pjmlp
4 hours ago
There is nothing to save as long as it relies on game studios using Windows workstations, coding in Visual Studio and targeting DirectX.
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 most stable Linux API is Wine/Win32.
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.
Those games did weird things. Every distro still ships SDL1, xlib did not break API, and requiring a specific driver is obviously broken from the start. I won’t say none of this happens but the platform isn’t to blame there.
Just like for OS/2, what a great success it was.
The development tools for OS/2 were worse and far more expensive.
It’s working right now, what are you arguing against.
1 reply →
There are a lot of older games that won't run on windows 11 as well. In fact most of my games no longer work on windows 11.
Your point?
Yeah? Most? So like what?
Targeting DirectX and Win32 has become targeting Linux with how good Wine/Proton have gotten. I am able to play brand new games with no Linux support absolutely perfectly through proton. These games run better than games that had linux support actually ran on linux.
Ironically, Win32 has sometimes become more universal than native Linux binaries. For example, Baldur's Gate 3 released a native Linux version only supported on the Steam Deck, whereas the Proton version is verified for Linux almost everywhere. Win32 became the stable Linux gaming ABI.
Thus making Linux irrelevant as target to game studios.
For them DirectX and Win32 is what matters, if folks go out of their way to run on Proton, that is Valve's problem.
You're assuming no game studio would test their windows executable on proton, just because they develop on Windows. If there's non-trivial market share to capture by being "Deck verified" I don't see why that would be the case. Game devs develop on Windows for PlayStation, Switch, mobile etc. At least with proton they don't even need to cross compile.
I wouldn't go that far, I would suggest that any game studio interested in the next 10 years of PC gaming will need to at least start doing testing through Proton/Wine to ensure there's no clear/prominent bugs. It doesn't take a lot of vocal users to elevate or kill a game, and Linux usage has passed that mark at this point... Generally seismic shifts in politics are around the 8% mark in terms of overall population, and Linux usage in the Steam survey is close to 4% and some other metrics have Linux usage over 6%.
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.
Like they were making native Linux clients before?
And studios definitely check out their games running on Steam Decks via Proton now, so that's good.
> Thus making Linux irrelevant as target to game studios. For them DirectX and Win32 is what matters
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.
1 reply →
UE can be crosscompiled on a windows host to linux and then it's a few checkboxes to enable the vulkan RHI.
The only thing that will make native executables attractive is users. A lot of users. Much more than Macos, seeings as few bother with Mac clients either and there's not even a Wine equivalent.
nothing stopping them from developing on Linux workstations, cross-compiling to Windows, and testing with Wine/Proton. saves them Windows license fees too.
The incentives are not there, as it is, they work as usual, and Valve is the one that has to make it work.
I don't see what the problem is with game studios buying Windows licenses.
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.
The top played games are not the ones made this year
Frankly, WINE/Proton are likely more consistent targets for game dev/testing... I wish they'd at least do that much more often than not. At least smooth out any rough edges.
I would say it's a lot different, since it's an API implementation, not hardware emulation.