Sorry I am repeating myself and usual disclaimer that I’ll continue only pulling in commits/PR changes that don’t break compatibility. So in many ways you should probably ignore me.
I would think all of these prompts the question, why?
Since I believe most of the deprecated code is from quite a few versions ago this is probably fine, but are there really that many, or any, deprecations in the rendering layer? Maybe I just haven’t looked at the code in that layer for a while.
Removing JSB is NOT equivalent to using Cocos Creator, I don’t personally care as never having used it since I’d rather use a simpler and more streamlined game logic scripting with non-cocos2d Lua/Javascript. However, for anyone using JSB it is far more work to move to Cocos Creator than it would be for them to re-add any support of JSB you remove.
Not sure why you need to remove support for Builder/Studio Editors? The parsing and node creation code of CocosBuilder/Studio should be higher-level than rendering layer, no? Maybe I just haven’t looked at the internals of these codes recently enough to realize that it’s intertwined with the rendering layer. For me I’ve never used Studio, but most games have at least simple/basic CocosBuilder menu scenes.
I’m also not even sure which parts of “3D codes” you would remove since the engine is a 3d engine that focuses on quad rendering (e.g. Sprites)? I would think all the simple mesh creation and rendering and lighting stuff should all be easy to continue supporting with Metal since they’re mostly higher-level than the low-level rendering layer?
Creating an object with verts, attributes, textures, and an associated shader+uniforms should really apply to any and all aspects of the engine? Maybe just consider making the new backend API easy to create meshes from array of verts whether just 4 verts (Sprite), 9 verts (Slice9), or any number (Mesh). Maybe make it easy to define the attributes of the verts, make it easy to apply uniforms, make it easy to apply a custom shader code, etc.
Edit: I realize that there have already been breaking changes version and you haven’t really followed any versioning scheme so really we’ve had I don’t remember version exactly, but something like:
- 3.0 (breaks from 2.0)
- 3.3/3.4? (broke a few things)
- 3.9? (changed rendering)
- 3.13? (breaks simpleaudioengine)
- 3.16? (breaks build workflow)
My main concern I guess would be allowing for fixes to previous versions while moving forward, but since that’s never really been a thing with cocos2d again probably just ignore my opinions.