How about remove 3D related and some other codes when integrating metal?

How about remove 3D related and some other codes when integrating metal?

huh, thanks for correcting me! It looked like the it was a 2d game but when you won a level and the log broke apart that animation looked 3D.

But on that note: “Steps” was a 3D game written in cocos-x. But the author felt that it was a “painful” experience and also that the 3D part of cocos-x had performance problems.

It always felt like the 3D cocos-x code was more experimental than production ready.

No problem, that’s the magic of good animation :wink:

You can reimplement some code when models loading and doing static batching for meshes.
All tree stubs are drawing in one drawcall, and grass in one drawcall.

‘Prestigio psp3506 duo’ gives 20 - 30 fps for this. (30 is stable without grass)

Because 3D will be removed, so there is currently no plan to create a gltf importer. Right?

3D is super important to my current projects. I would need this work.

But the other three aren’t important to me at all.


If you are trying to do all these stuff (OpenGL ES 2/3, Metal, Vulkan) by yourself it will take years to create a GameEngine with same features as Cocos2dx v3.X. I just read some documents about all these APIs… this will be some hard work for you.

I know that no one likes the idea to begin a new Project with the old openGlEs2 engine… but I mean most Devices on the market still support openGL… so there is (still) no hurry atm.

My suggestion would be:

  • It’s not about the amount of features (new features)
  • Important: Design the new Engine 100% backward compatible. Porting from v3 should be possible (and some kind of easy)
  • Design the API future-proof. That means implementing new features should not lead to re-designing the already existing structure.
  • 3D related stuff will be needed. If you do not implement it… you will get tons of requests in future.
  • 3D should have a lower priority for now. but…
  • 3D stuff should be planned now and designed well… like I wrote above… implementing it later should not lead to redesign the engine… this really should be designed carefully.
  • Another thought could be to design the engine modular. Devs could load/implement 3D API (or other APIs) independently in Cocos Console. So the Base Engine would still be a lightweight 2D Engine.
  • Last but not least: VERY IMPORTANT… a Documentation! Every little function should be documentated and explained… like it has to be in SoftwareDevelopment. It doesn’t mean anything if there are tons of features but no one knows how to use them. cocos2dx v2 documentation was great (good tutorials. Many documents in english)… cocos2dx v3 changed so many times that all documents was outdated within month. CocosCreator Documentation is the worst atm. As Example: CocosCreator has the Extension Feature… so everyone should be able to extend CocosCreator… but the Documentation so bad… that its a pain to create Extensions. Almost no english Docs… and half empty Documentation.

CocosBuilder, CocosStudio, JavaScript Bindings and Deprecated Codes should be removed.

I like your informative forum threads about this Topic. A Roadmap (with Milestones) would be nice.
Thank you… and good luck with this project.


Here’s the 3D app I’m working on: That’s a link to the version based on cocos2d-iphone, which I’m probably about 90% the way through recoding in cocos2d-x.

1 Like

I am fine with all of this.

We’re using 3D part too. If it will be removed, so we couldn’t user cocos2d-x anymore. Please, save it!


Yep, 3D part will be saved.


Please save these.

1 Like

cocos studio will be saved since cocos2d-x tests depends on it. But i don’t think cocos builder reader need to be saved, it is not maintained a long long time ago. As i know, the cocos builder editor is not maintained too.


Yes, I was talking about cocos studio.

1 Like

But can someone please update the flatbuffers dependency, because Cocos Studio uses it and I’m not able to verify if my changes worked, because I don’t have any data. Also see my topic for that.

I’m deeply concerned that such a thread popped up without any notice. An email would have gone a long way to actually gather user feedback from a larger developer-base as opposed to those that just stumble across this forum from time to time?

I replied to points as I read this thread, reading the ending conclusion after voicing my concerns, so I apologize if it appears to argue an already decided point

I agree with this point deeply

This is also a critical point and has continued to be for the past few years.
The main things missing from documentation are proper definitions of:

  • Expected inputs
  • Expected outcomes
  • Fringe/cases/ exception cases

for all functions.

What are the statistics on this? This thread is full of a lot of guesswork and there’s no actual metrics on the feedback in it. I for example maintain an application with tens of thousands of daily users which relies on the 3D features of cocos2dx and on csb parsing (Cocos Studio was still supported during development, and we still use it to this day)

If I add the game that I work on that has a large playerbase and relies on 3D does this validate my claim there are large projects relying on it?

Thank god, finally some good news as I read this thread.

Does this mean that csb parsing will still remain implemented? (CSLoader, Timeline etc)

Yep, you are right.

Great news!

The only big remaining concern will be how easy (I presume not at all) it will be to switch out the renderer or to port a 3.X project to this… moving files to a new cocos2dx project isn’t really an answer for pretty entrenched game.

We will release alpha0 version quickly, you can take a look. I don’t think it is hard to do, especially if you don’t modify engine codes.

1 Like