That's pretty much self-inflicted issue.
> If you only care about Windows and Linux, you can also just use DirectX and require users make use of Proton.
Proton drags in Wine, so it is even more heavy-weight than MoltenVK.
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.
... At least for commercial, closed source stuff.
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.
This way you can evade proprietary DirectX12.
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).
Ironically most of those games use DirectX with a translation layer.
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.
Metal was version 1.0 and used in production a year before there was even a proposal for Vulkan.
Why would Apple go all in on Vulkan?
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 :)
Because of the Steam Deck
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.
Apple doesn't support Vulkan.
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.
Apple is the only party to blame here.
I'm fine with passing blame to all those parties for not getting it together and making Vulkan a first-class citizen. But reality is reality, they're not - Vulkan is a second-class citizen for all those HW manufacturers - ignoring that doesn't help.
Nintendo -> supports Vulkan natively
Sony -> supports Vulkan (as per latest patch notes of BG3: https://baldursgate3.game/news/hotfix-9-now-live_95 )
Xbox -> Doesn't support Vulkan
Microsoft Windows -> Supports Vulkan natively first class.
AMD/Nvidia/Intel -> Supports Vulkan as First class APIs.
Android -> supports First Class Vulkan APIs natively.
Linux -> supports First Class Vulkan APIs natively.
Nintendo and Sony prefer their own APIs, NVN and LibGNM, and AIUI Vulkan is a second-class API on those platforms which does not offer as much power, it is widely understood studios use NVN and LibGNM to get access to the real hardware on those platforms.
Windows/AMD/NVidia/Intel -> HW manufacturers tend to prototype and release new features with D3D first and then 'backport' them to Vulkan after a while. DirectX 12 for example had mesh shaders for over 2 years before Vulkan got a vendor neutral extension for them[0]
Android and Linux are the only platform where Vulkan is a first-class citizen.
You could maybe argue Nvidia treats Vulkan as a first-class citizen because they tend to have vendor-specific Vulkan extensions for the latest features available before anyone else. But otherwise, no, Vulkan is not a first-class API anywhere except Linux and Android.
Graphics API wars are alive and well.
Making them in the end hardly better than multiple backends, when doing serious stuff across multiple GPUs and OSes.
Don't get me wrong. I agree that it's less worrying to know beforehand that all the features will be available in the target environment with features made mandatory rather than extensions. But, it's not like the case of Apple/Sony/Xbox which has software tailored for the device.
Vulkan devices range from Virtual devices(Moltenvk) to Android(Low powered devices) to Desktops(Linux, Windows) to Workstations(Linux). Having ray tracing mandatory in low powered devices like low budget android phones doesn't make any sense, that's why it's made as extension.
But, you can be sure that any modern desktop with modern GPU by any vendor atleast adheres to Vulkan standard and has specified extensions available. That can't be said about experimental extensions though (Like Vulkan Video).
> Making them in the end hardly better than multiple backends, when doing serious stuff across multiple GPUs and OSes.
This "multiple backend" solution is not ideal too. Firstly, it was necessary because not all Vendors supported single Graphics API standard. Secondly, it isn't powerful as main API it gets translated to(DX,Vk,Mt). Thirdly, I don't see how it helps when target environment doesn't have an extension available.
Maybe "Multiple Backend" solutions might make few things easier like removing Verbosity and maybe they are good for Small applications but I don't think they are worthy replacements to Main APIs
How many cross platform applications have you shipped with Khronos APIs?
I did my graduation thesis in 3D particle visualisation and marching cubes implementation, based on a framework ported from NeXT/Objective-C in Windows/C++, using OpenGL.
Contributed to SDL, Ogre3D and jMonkeyEngine.
Also contributed to some BabylonJS stuff in WebGPU.
What are you 3D credentials?
What is the best alternative to Vulkan extensions in your opinion? Remember that Vulkan supports vast number of devices. I think that making featureset mandatory for all devices is not sensible approach here.
> Contributed to SDL, Ogre3D and jMonkeyEngine.
> What are you 3D credentials?
Appealing to Authority[1] is a fallacy/bias and a quick way to lose a debate.
Instead of saying you have all these creds and therefore your opinion matters more - explain why what you are arguing against is bad. If you are an actual expert, that will be shown through well formed arguments all on it's own.
Not all experts share your opinion, clearly, which makes this angle unhelpful.
Life is too short to bother.
Erm, no? Vulkan is completely implemented in GPU vendor driver DLLs, Microsoft has no part in this. The only first class 3D APIs on Windows are the D3D APIs.
In reality, Vulkan doesn't matter much except on Android and Linux.
Thus said, even though Microsoft doesn't support Vulkan officially, you can tell that Vulkan has first class support on Microsoft Windows given that all GPU drivers have good first class Vulkan support and all Vulkan Applications run just fine on Windows.
> In reality, Vulkan doesn't matter much except on Android and Linux.
No, it matters. Vulkan is the first modern cross platform Graphics API which can run across Linux,Windows,Android,MacOS,Switch to name a few. No similar API does exist currently which offers high performance along with being portable.
Why would Apple support something that appeared two years later than Metal?
And as others pointed out already, Android and Linux are the only platforms where Vulkan is first class.
Because Vulkan is Open Standard? It's similar to how EV car manufacturers other than Tesla are now embracing NACS even though it was born at Tesla. It's also similar to how Apple adopted USB C given Lightning was already a standard before USB C.
You can't blame community or Khoronos either. Khoronos and developers did their best with best effort Vulkan-> Metal translator with Moltenvk and you can now not worry that your Vulkan apps won't run on MacOS(exceptions are heavy games and there are still many Vulkan extensions not implemented thanks to Metal).
And note that it's not you or I who is losing because Apple didn't support Vulkan. It's Apple themselves whose Mac devices have started losing share in Gaming Market. Day by day, Developers are ignoring MacOS as target. If this isn't a warning call to Apple, i don't know what is.
Why didn't Microsoft immediately embrace it? Or Sony? Or...
> You can't blame community or Khoronos either. Khoronos and developers did their best with best effort Vulkan-> Metal translator
Yes. Yes, we can and should blame Khronos. For their mismanagement of OpenGL. For the fact that they woke up and decided they needed a new API a full year after both DirectX and Metal, and managed to release first version a full two years after those two.
> And note that it's not you or I who is losing because Apple didn't support Vulkan. It's Apple themselves whose Mac devices have started losing share in Gaming Market.
Ah yes. They are losing because of not supporting Vulkan.
Let's see:
- iPhone is Metal (before you say that more people are gaming on Android, iOS's mobile gaming revenue dwarfs Android)
- Xbox is DirectX
- Playstation is GNM and GNMX
Apple is losing, should abandon Metal and go all in on Vulkan because.
Because they are already established platforms in Gaming Industry? Windows has much of Gaming market share. Xbox and PlayStation are popular Consoles. They probably don't loose anything by supporting Vulkan although supporting Vulkan would be awesome on their part.
> Ah yes. They are losing because of not supporting Vulkan.Xbox is DirectX. Playstation is GNM and GNMX
I was only talking about MacOS.
> before you say that more people are gaming on Android, iOS's mobile gaming revenue dwarfs Android
I didn't talk about iPhone either. I was only talking about MacOS. despite being prominent OS, game title developers often ignore MacOS. Why? Because of Graphics API. No one bothers to target Metal for Games and this is exactly what i am talking about. If MacOS allows Vulkan or DX(ik that it's not possible), i think there could be more influx of games.
If we are talking about Gaming on iPhone, you must know that gaming landscape on mobile phones is vastly different than that of mainstream gaming experience on Consoles/PC. Mobile gaming landscape is mostly filled with non graphics intensive, micro transactions filled, Ad-filled(many times freewares) games. iPhone gets targeted because it has prominent share in Mobile Market but even then, not everything gets ported to it. Not to mention, Android gaming landscape doesn't suck than iphone. Prominent Mobile games which are on iPhone are on Android too and on Android they use Vulkan which proves that Vulkan is not a bad choice.
> Xbox is DirectX. Playstation is GNM and GNMX
Vulkan probably runs on PlayStation (see latest Baldur's Gate 3 patch notes; grep for PS5 Vulkan) but I am not so sure. Like i said earlier, these platforms are already household names when it comes to gaming.
My point was not to tell you that Vulkan is the "supreme" Graphics APIs out there. But my point was to tell you that Vulkan is the only one of "supreme" APIs which is most cross platform, modern, supported by gaming and graphics forerunners(valve, rockstar, nintendo) and there are no viable alternative to Vulkan right now.
> Yes, we can and should blame Khronos. For their mismanagement of OpenGL
What should they have done? At the point, we needed modern Graphics API. Mantle by AMD was forerunner and AMD was willing to co-operate. Nvidia too joined that bandwagon. Thus, Vulkan was born out of Mantle.
Should they have copied Metal? Since it was closed API from Apple, it wasn't possible. Should they have copied Microsoft's DX12? If Microsoft actually loved Open Source and Standards and gifted Khronos DX12, it would have been possible but they didn't do it. I think Khronos did sensible thing at that time.
- you're willingly ignoring other platforms that Apple has and that are more important to Apple than Mac
- you're willingly ignoring the fact that Apple never care d about gaming on Macs
- you're pretending that gaming success is predicated on supporting Vulkan even though huge gaming platforms never supported Vulkan, and are successful
But sure. Apple absolutely must support Vulkan on Macs because they are losing out or something.
> But my point was to tell you that Vulkan is the only one of "supreme" APIs which is most cross platform, modern, supported by gaming and graphics forerunners(valve, rockstar, nintendo)
1. As if Apple (or anyone really, see Microsoft and Sony) cared about it being crossplatform and modern
2. There are thousands of game developers, and a very small number of those "forerunners" care about Vulkan.
> What should [Khronos] have done?
Not sit on their asses until it was two late. Both DirectX 12 and Metal were released in 2014. It means that Apple and Microsoft had been working on these new APIs since at least 2012.
Khronos woke up and decided to create a new API in 2015.
It's amazing you're blaming Apple and Microsoft for not doing something for Khronos out of the goodness of their hearts when the "amazing open innovative forerunners" like NVidia, AMD, Valve, Epic etc. are their members and literally did nothing until, well, it was too late.
If you only care about Windows and Linux, you can also just use DirectX and require users make use of Proton.