Scene is a Layer

cocos2d-x C++
#1

Hey, is there any plan to make Scenes actually derive from Scene, or is there some specific reason why a Scene is a Layer, and then added to a Scene? Seems overly confusing for no reason, can someone explain the logic here?

The fact that this code breaks is kinda ridiculous:
GameScene *scene = GameScene::createScene();

I know exactly why it doesn’t work, but it makes things a little messy.

Every time I think of a good reason why it might be like that, I think of 5 better ways to approach the situation.

Thanks

#2

Scene is a Node

You don’t really need Layers1 if you don’t want to use the, You can change the z-order of any Node thus changing the order in which it is rendered on the scene graph

http://cocos2d-x.org/programmersguide/2

Can you help me understand what you are working through?

#3

I’m not really dealing with a problem, its just more confusion around the design choice behind the default way of creating a Scene.

Why call it a scene and derive from Layer? Layer and Scene both derive from Node, so calling them Scenes, then deriving from Layer just looks weird.

Why don’t scenes derive from the logical Scene base? and allow us to simply create using our own constructors, provided we call the default base constructor for autorelease pool stuff etc.

A scene should just be a scene, and contain a layer, which you can access and add children into. This way a scene can be left to do “Scene Stuff” and we don’t have weird looking creation and initialization.

#4

Scene does not derive from Layer though…

#5

I’m talking about the default examples, it shows you how to create YOUR scenes by deriving from Layer. So, the base Scene class doesn’t derive from Layer, but most Scenes created for games DO.

My game has the following code:

  1. class GameScene : public Layer

  2. static Scene* createScene();

  3. CREATE_FUNC(GameScene);

    Scene* GameScene::createScene()
    {
    auto scene = Scene::create();
    auto layer = GameScene::create();
    scene->addChild(layer);

     return scene;

    }

All taken from cocos2d-x documentation. Maybe I’m not explaining myself properly?

#6

oh, I see. Perhaps our examples should be re-wored for best practice.

Take a look at the Programmers Guide Samples: https://github.com/chukong/programmers-guide-samples

One of the things we do here is inherit from Ref and we don’t use Layer

#7

Thanks, I’ll take a closer look at that link. Though I still don’t quite understand why the game scenes, which you push, pop, transition etc using the director don’t actually derive from a Scene. But rather have a convoluted way of using a static method to create a scene and add themselves to it.

Wouldn’t it just be much more clear for game scenes to actually be derived from Scene? I’m just trying to figure out what the logic is behind a Scene being a Ref or Layer.

#8

I faced that problem too. Simply forget about Layer:

http://www.cocos2d-x.org/wiki/Layer

Layer seems to useless since v3.0, because now all Nodes can receive touch events. It is reserved just for compatibility. It may be removed in future.
#9

I see what you are saying. I think we need to re-work the templates that our users tend to get started with.

I’ll create a Cocos-Dev post for this so we can talk about it.

#10

Hey guys, I’m only talking about the fact that if I stop using Layer, I’ll be using Ref or something else. What I’m really asking is, why game Scenes aren’t just derived Scene classes? I know the documentation is going to get updated and the cocos2d-x team has done an awesome job already with everything. Just wanted to get a response around the reason why Scenes aren’t just Scenes.

I’d like to remove the CREATE_FUNC and static createScene and simply use a constructor/factory method that ACTUALLY construct/return my GameScene.

The other issue is that my GameScene class has a few public attributes that I’d like to use to get data into GameScene prior to pushing using the Director. Currently I use a Singleton which my Scenes all share and modify/read as needed, but this is bad architecture in my opinion. I’d much rather pass objects/refs to my Scenes and remove the Singleton glue that binds them. This is all because createScene() returns a generic Scene object (since GameScene is actually a Layer or Ref) and I can’t access my public attributes directly and things get ugly.

#11

Agree on all points raised by Nick.

Scene is just weird.

I have to jump through hoops to work around this. I can’t share data except by having Singletons. I can’t have a common GameScene that gets initialized with the right attributes (e.g Mode=Game/Mode=Demo/Mode=Practice), using the current CREATE_FUNC.

#12

Hey, I ended up not using CREATE_FUN and just redefining what it does in my Scenes. This was createScene() and create() can take parameters and hand them off to the Scene itself. This removed my need for a shitty singleton.

For example, I needed to get a unique_ptr object into the GameScene:

static GameScene *create(unique_ptr<TriptychGame> game)
{
    GameScene *scene = new GameScene(std::move(game));
    if (scene)
    {
        scene->init();
        scene->autorelease();
    }
    else
    {
        delete scene;
        scene = nullptr;
    }
    return scene;
}

Viola, you can kick CREATE_FUNC to the curb.

#13

I myself is having problem with this Layer vs. Scene. To my knowledge, I insert sprite into Layer and Layer is added to a scene. Consequently, Scenes are compose with Layers. Having this thought, I saw my Scene is completely useless having all the code bunch on Layer classes. I am still confused. Forever confused.

I think I will not use layer but instead use Scene as per this documentation and marcelocontarini:

marcelocontarini
I faced that problem too. Simply forget about Layer:

http://www.cocos2d-x.org/wiki/Layer

Layer seems to useless since v3.0, because now all Nodes can receive touch events. It is reserved just for compatibility. It may be removed in future.

#14

Because of the f**king retro-compatibly features, a lot and a lot of beginners fail to learn cocos2d-x, even expert programmers find difficulties to track their code, there is a lot of useless crap in cocos2d-x : Matrix Stack, Layers, Render Features, Useless Children Sorting Call, Creepy Scene Templates, Super Slow RenderToTexture, Getters, Setters… :rage2:

#15

Which ones?

Some of your claims are not even related to cocos2d-x but to a language. E.g., C++.
How could someone expect to learn cocos2d-x, if they have to learn the language beforehand?
Many problems on the forum are related to knowing to little about the language, not the engine.

You have to learn how to crawl first, not to fly :wink:

Not all, but maybe only some.

Which are useless?

Matrix Stack:
What is useless about it?

Layers:
What is useless about them? They are a basic concept.

Render Features:
What is useless about them? Which of them?

Useless Children Sorting Call:
Since when is sorting useless? Which sorting exactly?

Creepy Scene Templates:
Didn’t know, templates can be creepy. What is creepy about which one?

Super Slow RenderToTexture:
Which one? How about implementing it with OpenGL calls… Wait! getPixel/putPixel was always slow, hence you should use another approach. It’s not the fault of the engine.

Getters/Setters:
What is useless about them? They are a basic concept. What do you suggest instead?

If you make assumptions or rants, please explain WHY you think that way. Bring arguments!

How should a framework evolve, if you don’t back your claims with arguments? Saying all is just crap/useless will lead to nowhere.

#16

1-Matrix Stack is only there for cocos2d-x 2.x compatibility reasons since cocos2d-x 3.x uses AffineTransform to pass ModelViewMatrix.
2-Layers are useless because every nodes in cocos2d-x 3.x can receive events, so using them will just add a layer of complexity to your game.
3-Children Sorting Calls are not needed anymore since sorting is done in cocos2d-x 3.x on the level of the render.
4-Old templates doesn’t take advantage of cocos2d-x 3.x new features.
5-RenderToTexture should handle FBO/MultiPassPostProcessing in a efficient way and reduce the work done by the developers, but most of them(Including me) use direct opengl to handle such task because RenderToTexture are slow(super slow…) and this due to the retro-compatibility.
6-Some getters/setters should be removed or replaced with direct value access, because most of them are virtual, and virtual function calls as you know are much slower than normal function calls…

#17

Thank you for explaining your points.

Things like eventlistener, box2d and others depend on it, but are these 2.x only features?
http://discuss.cocos2d-x.org/t/shall-we-remove-matrix-stack/19950/13

If’s often not owed to compatibility, but just to planning a re-implementation of dependent systems.

They are totally optional. You don’t have to use them, but you can if you want to.
It’s your choice, totally up to you.

Again, isn’t it up to the developer to decide the route to go?
They are not a requirement to use. Why getting rid of something, which is just optional?

On this I agree. Well, I think we all agree on the lack of documentation.

Yes, the engine is lacking of some features, but the engine does not prohibit you from implementing it yourself.
The task of an engine is not to spoonfed every single bit the developers asks for.

You mention in some other post, that you change a lot of the engine source for “optimal performance”. Is there a chance, that you could provide those changes, so everyone could benefit from it?
If you already did, great! Thank you for contributing.

No engine out there can please everyone’s needs, but the fact, the engine is open source with full source code access, means, the community can alter, add, change and provide the features needed or the things developers complain about.

Be the change that you wish to see in the world.

Direct value access violates one of the the OO paradigms: Encapsulation
Should we drop that, just because it’s more convenient to have direct access to anything for anything?

It depends. If the object type is known, it will just be a normal function call. Not every time there is a virtual dispatch.
Virtual function call performance only matters in frequently called code. Are those getters/setters called frequently? If so, they might slow down the code.
But there are more important parts, that you have to consider: code with branching! A lot of the base code of the engine is using branches, which is a more important part to consider.

Altering the engine to a data oriented design with branch-less code, may leads to an unparalleled performance speedup. Who knows. I guess virtual functions would be negligible compared to the real bottlenecks.

But yes, virtual functions can be performance killers, as any OO design.

Back to C then :wink:

#18

Actually I’m using my own Cocos2d-x, I call it “Nuclear”, to be honest Nuclear(Based on cocos2d-x 3.2) is super fast comparing to the original cocos2d-x, note : Children Sorting is not optional, it’s in Node.cpp code…

#19

You should rename it to Nucleus and we could rename to Pied Piper :smile:

#20

Sorry, my bad. I was thinking of user sorting, but I guess you were referring to sorting regarding batching.

Is it possible that you provide some benchmark results of both?

Do you have any plans to make your changes available?