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

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

#1

As mentioned in this thread, cocos2d-x will support metal. When adapting metal, it will break some APIs, so it is time to remove some codes that are not good implemented or out dated, such codes are:

  • 3d related codes
  • deprecated codes
  • Javascript binding codes: suggest to use Cocos Creator instead
  • cocos builder and cocos studio support codes

What’s your opinion of these changes?


Progress of new backend API
#2

#3

Positive about #2 #3 #4. I’m not sure about 3D related codes even though i’m not using any 3D features in any of my games. But i think many other developers using it.


#4

1 ) We had used 3d features in few games, but i think we should remove it as its not production ready usable.
Though lets see what others say
2), 3), 4) this should be fine


#5

I would prefer to not remove 3D code. Maybe v3.19 or v4.0 could include a production ready API for 3D. This shouldn’t be rewritten from scratch.


#6

Hi.
It’s OK to remove 2,3,4 and remove 3D stuff temporary for clean 2D API. Add 3D stuff in the next version.


#7

Well I’ve put several years of my spare time into deleveloping a 3D game using cocos2d-x, so you can imagine I’m horrified by this. It seems a step very inconsiderate of your community. It would hurt some badly. I’ve never seem anything in the documents that suggests 3D is in any way experimental - no warning that something like this might be considered.

I’m hoping this is maybe a joke? We have a 1st of April thing over in the UK. Maybe this is similar. I hope so.


#8

@Glidos take it easy, i set up this thread just to check if 3d feature is used or not, since cocos2d-x doesn’t have a good editor for it.


#9

Okay, that sounds less worrying. My vote is please keep it then. :sweat_smile:


#10

I am fine with everything above mentioned to be removed. 3D is good but I think there are other software(s) which take charge in this area.


#11

There are other considerations here. Everyone posting here “Yeah fine, take it out, I’m not using it”, should consider whether there are any other parts of cosos2d-x that they may be relying on but not many other are. If 3D can be dropped, so might something else that you do need.

And for new people thinking of starting a big project. Can they trust that what is in cocos2d-x now will continue to be mantained far enough in the future for them to finish the project?

Also, I just stumbled on this thread by luck. A great many users may not see it. It would be good to place some sort of warning on the main website, with maybe a link back to this thread.

Longer term, I’m wondering will Android and iOS continue to be supported. I know there’s been a lot of focus on web-based apps lately.


#12

A visual editor is in no way required in order to work with any game engine. Sure, it’s nice to have for people who want to use it, but it is completely unnecessary, and should not be the deciding factor on whether to keep the 3D implementation in Cocos2d-x. Besides, if anyone ever needs an editor, and they’re willing to invest time into it, then nothing is stopping them from writing one top of the Cocos2d-x engine.

Anyhow, the 3D support in Cocos2d-x at the moment seems more than good enough for what developers may need, and it’s actually quite useful.

So, please, do not remove the 3D support.

As for items 2, 3 and 4, I personally don’t use any of the functionality from them since they’re quite out-dated, so if they are removed they won’t affect my own projects, but I can’t say the same for others. For items that have been previously set as deprecated, then it is about time to get rid of them for the sake of code maintenance going forward.


#13

keep 3D related stuff for now. you have the option to remove 3d physics etc in ccConfig.h

removing the rest sounds good :smiley:


#14

Removing 3D related API’s means again a “step backwards”. Most GameDevs are interested in to make 2.5D and 3D Gamess (in near future). I’m honest I was expecting full 3D support for CocosCreator in 2018.

Remove all other mentioned points.

And you (as team) should also focus on improving cocos documentation. The bad documentation is the most important reason for me to think about continue using cocos2dx/CocosCreator for future projects. Documentation should have first priority at all. it’s frustrating to search for solution for hours and hours abd find nothing!

I realized also that the cocos team starts many projects like cocos builder, cocos studio and throw them a few months later away. Just dont “reinvent the wheel” again and again.

I don’t know if i’ll continue using cocos2dx… but that’s my honest opinion.


#15

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.


#16

I would also ask that you don’t remove 3d code. Not sure exactly what parts of it you’re talking about, but I do mesh rendering in my 2d games (with 10 million+ downloads) and use TrianglesCommand extensively. Without that I don’t think I could use Cocos2d.


#17

I am working on a commercial game using cocos2d-x JS. If you remove JSB, that would be a bummer for me as I wont feel comfortable migrating inheritance based JS logic and 20k lines of code to CocosCreator.

I love cocos2d-x and if you remove JSB, I will have no choice but moving to Unity for my next game.


#18

@zhangxm
I really think that for business viability and supporting as many developers as possible :

  • Remove the 3d part completely as i never saw successful cocos2dx 3d game …
  • keep the JS binding as i know big companies are using it simply because JS developers are easy to hire and code is easier to maintain .
  • Personally i wish you go back to the simple easy version 2 of the engine and
    keeping the engine light and fast

#19

From all the onions, it seems that i should keep all things, and it will be ok for v3. From v4, i will do above things and make cocos2d-x simple and fast.

The reason why i want to remove these things in v4 are:

  • 3d feature is not designed well, it break some 2d features and make the engine more complex and slow down the engine. My be we only have to support rendering 3d object and animation, not other things.
  • Creator is better if you want to use Javascript, it has an editor, and more javascript friendly.
  • cocos studio is canceled for a long time, cocos builder is not maintained for a long time too, so corresponding codes are not meaningful

#20

Having an editor is not really a plus in my opinion. I’m a programmer and I like doing things in code. As for JS in Creator, it uses an entirely different component based approach and I prefer working with the classical inheritance based approach in cocos2d-x.