Don’t use Proton as API. It is a compatibility layer trying to implement what Microsoft’s implementation probably does. Use Vulkan or OpenGL if you can.
Proprietary APIs? In 2023 we shall all know to avoid them. It is not 1998.
The unfortunate move from Apple is Metal instead of going all in for Vulkan. And now they struggle and need foster native ports. They shall support itself Vulkan and improve it - and therefore improve support of Linux and MacOS.
I'm exclusively on Linux, a casual gamer, and native ports suck. They probably can be done better, but you still run into the problem that some Linux game released 5 years ago doesn't even launch anymore on current distros.
I've tried to play the native port of lis2 only to be greeted with a "hey this game needs an AMD or Nvidia GPU" warning, which I could click past only to have the whole system freeze in the main menu. That was literally the first ever crash of that machine ever (about 14 months old at that point). Luckily steam allows you to force using the windows version of a game even if a native port is available and guess what, no warning about GPU, game worked flawlessly. And it very likely still will a decade from now. How many native games released today will?
Morale of the story: win32 is the only stable userspace API on Linux. Develop for win32 and test on Linux, boom you got your multi-platform game.
You probably should blame the people which made the game? We face the same issue on Windows, too. Low quality ports from console to Windows (e.g. The last of us). So it is more about appropriate ports.
Valves native ports of games - CS1, CSS, CSGO, CS2 [sic!], HL1 and HL2 run well on Linux. As the famous titles of id Software? As far as I know you can still run the original executable from Quake3 but it is not a wise decision (missing bugfixes, X86_32 and OSS). But they went the save way and just published the engine sources.
And? Proton's own foundation is Linux. And Valve layered a lot of complexity away with it Linux-Runtimes (the most recent is "Sniper 3.x").
I would be just happy if developers accustomed to Windows stop supporting specific (outdated) Linux-Distributions with awkward self made packages. Instead they should merely publishing ELF-Executables, the resources and a list of dependencies - and the maintainers will care. And aside they could ship one Flatpak, made itself. Both things are done by Valve :)
I think most of that issues come from "training" from Windows, where just everyone does the task itself and no rules for shipping exist. And when a developer isn't familiar with the target system and porting problems are more likely. Apple does handle this different, they force the developers doing it in the specified way (you don't get a certification if not).
> You probably should blame the people which made the game?
No, why, when there is a working alternative available. Why should they waste money and resources on this if they could just make the game better overall instead, or maybe just pour the money saved into wine/proton somehow, which benefits not just their game but every Windows game.
> We face the same issue on Windows, too. Low quality ports from console to Windows (e.g. The last of us). So it is more about appropriate ports.
Well yes and no. If the windows port sucks too, just use an emulator a few years down the line.
And funnily enough, wine is even more future proof for Windows games than Windows itself. You can find a lot of stories about old Windows games from the XP era and earlier that won't run on 10, but work fine with wine on current Linux.
Regarding quake 3, I can also still run the windows version of the original release on Linux, and in that case don't even need to care about OSS or anything because wine just does that for me. And sure, I'd rather play a popular modern fork of the original game since as you say, the source code is available, but my point is entirely about closed source games where we'll never see the code. If I'm dealing with a black box binary, I don't see what I'd gain even with a well made Linux port over the game running just as well under proton.
You know that Games/Applications can still be developed with Vulkan API targetting win32 and they can be run on Proton/wine in Linux which runs it without the DXVK (dx11->vk)/VKD3D (dx12->vk) translation layer, right? Baldur's Gate 3, Red Dead Redemption 2 are some of popular games which use Vulkan exclusively running on Proton.
It really doesn't make much difference whether the platform abstraction layer code is part of the game, or part of the runtime environment.
Each cross-platform game has such an abstraction layer, usually it's just inhouse code or provided by a game engine vendor. Moving that part out of the game and into a shared set of 'system libraries', maintained by specialists who actually know how the Linux graphics system works inside out is actually a very good thing.
That this abstraction layer implements a subset of the Win32 APIs really isn't all that important from a technical perspective (it is however very important from a business perspective).
I never heard a Linux users complain about game developers writing their games against SDL for instance, yet the basic idea isn't all that different from Proton.
Why they should?
Because it it would improve portability for their platform and Linux. And it weakens Microsoft. What we've instead, three competing APIs. Apple labled OpenGL deprecated and many rely now upon MoltenVK. At the same time Apple switched to ARM. Both in combination are problematic because AAA-Titles are closed-source. For the same reasons Apple supports OpenGL they also support Vulkan.
I wonder about the reasons of Valve to the decision to support Linux (Vulkan) and Windows (Direct3D) with native ports of CS2. But not MacOS. I'm happy because Linux is supported but the Mac people are obviously not so happy. AFAIK Source2 was already used in the past on MacOS.
PS: Thanks to Valve for the native port of CS2 on Linux :)
You mean it was ready when it was ready, and Apple released it. When Apple released it, Vulkun was not even an idea.
> Why they should? Because it it would improve portability for their platform and Linux. And it weakens Microsoft.
Why would Apple care about that?
The rest of that paragraph reads like a loosely connected stream of consciousness with no reasons for Apple to drop Metal and go all in on Vulkan.
To remind you, again, the timeline:
- Metal has been available since June 2, 2014 on iOS devices powered by Apple A7 or later
- The Khronos Group began a project to create a next generation graphics API in July 2014
- Vulkan was formally named and announced at Game Developers Conference 2015
- Metal has been available since June 8, 2015 on Macs (2012 models or later) running OS X El Capitan.
- On December 18, 2015, the Khronos Group announced that the 1.0 version of the Vulkan specification was nearly complete
- The full Vulkan specification and the open-source Vulkan SDK were released on February 16, 2016
By the time Vulkan was just released, Apple had already been running Metal on its devices for two years. By the time Apple released Metal 2 in 2017 Vulkan was 1 year old
> For the same reasons Apple supports OpenGL they also support Vulkan.
OpenGL straight up sucks to work with. DirectX 11 is a much nicer API that doesn't require you to write your own allocator for views in the GPU like the lower level APIs. Linux isn't a major platform I personally care about so I use DirectX 11
Don’t use Proton as API. It is a compatibility layer trying to implement what Microsoft’s implementation probably does. Use Vulkan or OpenGL if you can.
Proprietary APIs? In 2023 we shall all know to avoid them. It is not 1998.
The unfortunate move from Apple is Metal instead of going all in for Vulkan. And now they struggle and need foster native ports. They shall support itself Vulkan and improve it - and therefore improve support of Linux and MacOS.