> Apple is a sticky company to develop for and it isn't practical to have direct support for metal
Why is it not practical to have direct support for Metal? Honest question.
You get access to a market of over a billion devices across desktop, phone, tablet and TV, with iPhones and iPads having some of the best graphics performance in their class. Even more important for developers, Apple platforms generally have a much higher percentage of users on their latest OS versions than Android etc. Why wouldn't you want to get the most out of that by using their native API?
You can get pretty far just by adopting SpriteKit/SceneKit which use Metal under the hood. 3D is outside my ken so I haven't measured the performance for that, but for 2D even my sloppy pet project [0] could update 3000+ sprites every frame at 60 FPS on the 2 year old iPhone X. You can even mix in SwiftUI without affecting game performance! (that I can tell so far.)
This is a case where adding one feature adds a 2x scaling factor to your test plans. Add a game effect? Now you need to test it in Vulkan and Metal which means two test computers, twice as long to run a test, etc. It's just a logistical nightmare.
It makes even less sense when there are shims like molten which will translate for you. No need to run all of your test plans through their shim. Just a subset will do since they're likely testing their code.
You haven't eliminated it but it doesn't scale your workload the same. You'd likely be fine with having a tester play through your game on molten. In any event it is still much less code and testing than supporting multiple backend APIs.
It's not practical to have direct support for Metal because nobody who wants it is volunteering to write and maintain a new backend for it.
Godot is a project with limited resources and the Vulkan backend works fine on Apple platforms through MoltenVK, so as far as the people doing the work are concerned there's little point in adding Metal support and lots of other things are higher priority.
This is not a question for me. It's a godot decision. They seem to know what they're doing and have claimed that platforms that use metal are "not used very much".
They talk about macOS, "a platform not used very much" (despite there being over a 100 million users the last time someone counted), not "[all] platforms that use Metal" which also includes iOS/iPadOS and tvOS.
> Still, the lack of support on macOS made it unappealing. Having to write a Metal backend to support this OS is a lot of effort for a platform not used very much.
It seems with MoltenVK, Vulkan would use Metal anyway?
> MOLTENVK GOES OPEN SOURCE
> However, today, in a completely unexpected turn of events, it seems Valve has found an arrangement with the developers of MoltenVK (the commercial and proprietary Vulkan over Metal wrapper), ported Dota 2 to it, and got it open sourced.
> It seems to be a mostly complete Vulkan implementation that runs on macOS and iOS. This pretty much lifts the only barrier we had for moving Godot to it.
Yes and that is the last they’ve said about metal support. Mixed signals about its importance. It’s unclear how important it is to the godot development team and if it isn’t important it might simply not happen.
Why is it not practical to have direct support for Metal? Honest question.
You get access to a market of over a billion devices across desktop, phone, tablet and TV, with iPhones and iPads having some of the best graphics performance in their class. Even more important for developers, Apple platforms generally have a much higher percentage of users on their latest OS versions than Android etc. Why wouldn't you want to get the most out of that by using their native API?
You can get pretty far just by adopting SpriteKit/SceneKit which use Metal under the hood. 3D is outside my ken so I haven't measured the performance for that, but for 2D even my sloppy pet project [0] could update 3000+ sprites every frame at 60 FPS on the 2 year old iPhone X. You can even mix in SwiftUI without affecting game performance! (that I can tell so far.)
[0] https://github.com/InvadingOctopus/octopuskit