I’m just trying to offer suggestions for limiting the amount of work required
It was a mostly immediate gut reaction, and therefore probably aren’t valid for the real v4 development.
I think my only point is that if developers “need” Metal support for v3 then the team (or community) might as well try to pursue the least amount of work necessary to support it.
v4, however, should either be written with care for each target (Vulkan, GLES2/3, Metal, DX12) or might as well use a wrapper (e.g. BGFX/SDL) and only write target-specific backends after the rest of the improvements and new features or streamlined API is designed and written.
I do understand that a single back-end renderer, say a simple Metal render written in a new bare game project that doesn’t have to integrate into cocos2d-x’s API would not be a ton of work to get running, there are likely many edge cases and issues integrating with shaders and assets that will inevitably require more work than expected upfront. This likely multiplies with additional renderers.
Any given game should either write their own back-end renderer, or if we’re honest, just use one of the wrappers or already written engines that have Metal/DX support already built-in.
This is just my thought process on how I’d approach this for any future game where c++ and part or all of the cocos2d-x engine were to be utilized.
I’m also mainly giving any thoughts or suggestions based on the limited amount of development that has been applied to cocos2d-x (for c++) over the last few years. I’ll actually be surprised to see a true v4 of cocos2d-x as I fully expect cocos2d-x-lite to become v4 and otherwise v3 will just be iterated on into the foreseeable future.