You can't ship Game Porting Toolkit with your game, though. DXVK doesn't have this limitation, and developers use it all the time. In effect, this means the number of games you get with native Vulkan coverage is a magnitude higher than the total sum of all Metal-native desktop titles.
This isn't completely true. Crossover is allowed to ship the GPTK components for API translation (which they currently do as of 23.5) and games are allowed to embed Crossover elements like they did in the pre-Metal days with Cider etc.
All this talk of DXVK doesn’t explain why games based on engines with native metal support aren’t on a Mac either.
Crossover is a paid product, and even then has pretty poor DX12 support compared to Proton. Up until a couple years ago it didn't work at all.
Again; if Apple had just supported Vulkan alongside Metal like a normal non-paranoid company, their users wouldn't be caught in the middle of this. It's such a blatantly obvious solution with no user-facing downsides. It's shocking that anyone would defend the status-quo when it's so notoriously and obviously broken.
Prior to metal and Vulkan, many games used Cider to target Mac despite having the same APi (at that point, an up to date OpenGL).
And many of the current game devs do have Metal versions of their engines that they target towards iOS, yet don’t have a macOS version.
The fact of the matter is that it comes down to market share. Macs have historically not had a large user base that also had capable GPUs. It’s not been worth supporting that tiny market share
It’s the same on Linux. Why are there so few Linux native games? The argument that Vulkan would have solved this is completely incongruent with the reality of the state of gaming.
This will inevitably go back to “well at least we could have used proton” but that’s also not true, and besides there’s GPTK. And then the argument becomes circular , because all evidence points to: devs just don’t care about Mac’s from a support perspective. You can make it easier, they still won’t come until the possible demographic size is larger.
and even with DXVK, what about all the other platform specific differences? Vulkan wouldn't solve those either.
but it in fact did! You can play 90% of games on linux precisely because of Vulkan. Just boot Steam Deck or whatever and play. There is no way it would work out without Vulkan
And I address Proton specifically in my comment and also address why it’s not an indicator of increased gaming support on Mac.
I truly feel half of the replies here are glossing over the things I’ve already covered and perhaps are people who haven’t actually tried the equivalent Mac solutions and seen where the resultant deficiencies lie or the delta between platforms that proton would also have to bridge further.
Vulkan isn’t the magical silver bullet people think it is.
Conversely, I'm convinced that you haven't tried Proton and are trying to defend Cider and Whiskey as analogs when in-fact they are pale imitations. Gaming on Mac is derelict; you can get a few games working, but it's still absolutely pathetic stood-up next to Windows or even modern Linux. The number of playable desktop games is just a blowout for MacOS.
We've all used tinker-tool applications to get a random app running through WINE, but DXVK is more than that. It is the solution to a problem Apple refuses to address, and even Apple is willing to admit that they need DirectX translation in order to make games run on Apple Silicon. How is the future of gaming on Mac going to look any different if we continue to follow in the footsteps of Cider? How long do you think that shanty-utopia will be supported on the latest OS update?
Vulkan has nothing to do with the Steam Deck being able to run PC games other than being the API that DXVK and VKD3D-proton translate DirectX calls into. Vulkan isn’t the magic bullet, it’s just another API in the stack. The “magic” is the phenomenal amount of effort that has gone into those DirectX translation libraries.
Vulkan makes the work easier, but it is not what makes those games portable.
Yes and no. DXVK didn't happen on top of opengl as the impendence mismatch between OpenGL and DX is too large. Wine had working but slow DX9 to OGL; incomplete, buggy and slow DX11 to OGL; and no hope for DX12 to OGL. DX9, DX11 and DX12 are all much easier (but not easy, mind) to map to Vulkan.
As Steam Deck is running AMD, a conversion layer on top of Mesa Gallium would have been possible, but again DX12 support never materialized.
I mean I owned a Mac back then, I remember pretty fondly that pre-Catalina MacOS was a fairly well-targeted platform. OpenGL was working for them; you could play first-person shooters, online games with fancy graphics, the kit and kaboodle. Things weren't perfect, but there was a lot of functional cross-platform software back when Apple commit to maintaining common APIs. You cannot deny that an entire ecosystem of software that was once cross-platform had to now choose sides, if they would support Metal or OpenGL. I watched it collapse with a single system update.
> Why are there so few Linux native games? The argument that Vulkan would have solved this is completely incongruent with the reality of the state of gaming.
My brother in Christ, the "reality of the state of gaming" is that Mac owners are buying Steam Decks just to access the games Apple tries to kneecap. Vulkan fixed it, and Valve commoditized Apple's compliment.
I don't want things to be this way. I think Mac owners should have easy access to the games they want to play, but Apple insisted otherwise for so long and refused to ever admit that they were wasting their time. It's part of the reason I got rid of my Mac so I could daily-drive Linux; they were wrong, and other platforms were right.
Go back and see how many of those games were running Cider though. The switch to kill 32-bit games killed more games than the deprecation of OpenGL did. The number of games that targeted OpenGL was ALSO shockingly low.
This is something that OSS fans do not want to reconcile: Open source graphics APIs have LONG lost out to proprietary graphics APIs in gaming. OpenGL had a very small base in games, Vulkan is even smaller.
and again, you went exactly back to where I knew you would and pre-empted it because it's the obvious playbook of answers. Vulkan didn't fix gaming on Linux. Proton did. And again, you ignore the key part of the sentence: NATIVE
Linux has fewer *native* AAA games than macOS. Vulkan has not solved that.
The SteamDeck is a product targeted at gamers that provided a new value proposition: AAA gaming on the go. Which further reinforces my point that API is irrelevant to the discussion, its about demographic. Apple has a strong gaming demographic on the mobile side (with metal no less).
The steam deck didn't introduce new Vulkan/Proton capabilities. Why was Linux gaming stagnant before it? Doesn't that exactly reinforce that its the form factor proposition that made it skyrocket?
> switch to kill 32-bit games killed more games than the deprecation of OpenGL did.
It did. If you want to parade around how cool Cider is, it doesn't make much sense to venerate the update that killed it.
> Linux has fewer native AAA games than macOS. Vulkan has not solved that.
Imagine all the Steam Deck users that are pissed because they can't play Resident Evil 8 and Tomb Raider natively! They must be super upset, and envious of Apple's superior native version. Surely.
Hey, here's a magic question for you; which do you think will get supported longer, a DirectX title running on Proton or an Apple-native title running on Apple software. Do you trust Apple to keep supporting your game as long as Proton would keep supporting it?
Why do you have tunnel vision on "native". It's a pretty meaningless distinction at this point. No steam deck users cares that all the games they are playing aren't "native".
Precisely. Modern games incorporate all manner of middleware to add functionality. Compression, video codecs, shading, ray tracing, physics, animation, anti-cheat. What's one more piece of software in the pile to abstract away platform-specific interfaces?
Also Wine it's just a Win32 subsystem for Unix with a PE loader. Also, a hint: on NT Systems, Win32 it's another subsystem on top of the NT kernel. I'm pretty sure Windows 95/98 software under 2000/XP doesn't run 'directly' in the same they did under their original OSes.