Draw order in SB v1.4.7 (App Store build) is reversed

[LearnCocos2D]

draw order in SB v1.4.7 (App Store version) seems reversed - but maybe I just have a different expectation for some reason?

Ie in the image below my gut instincts tell me that the brown asteroid should be in front of the gray asteroid --> ie order of addChild = draw order so index 0 "gray asteroid" should be drawn behind index 1 "brown asteroid".

But it's not and I'm really confused about that. :(

[cocojoe]

It was reversed a while ago, to be inline with other tools, so background at the bottom and work up. gray asteroid should have the highest Z in your case.

[LearnCocos2D]

I took this to Unity (GUI) and it has it the same way as SB used to have it, ie "the correct way":

Personally I would strongly disagree and say that the current ordering in SB is the wrong way, no doubt about it. I understand some tools do it differently (which ones?) and the expectation of some people depending on their background may be different.

So rather than just switching this around, I would welcome a solution where anyone can decide whether the list of nodes is upside down or downside up without this actually affecting the draw order, just the order in the tree view.

But for any user who does any amount of programming - and there's hardly any way around that in SpriteBuilder - this will be a problem when they realise that the children order is the opposite of what's displayed / drawn in the editor.

[slembcke]

Photoshop and any graphics program I can think of always put the frontmost object at the top of the list.

[LearnCocos2D]

Yes, I know. But the point is: SB is not a graphics program, it's a technical design tool.

[NickyWeber]

What do users expect? Of course established users may get confused by this change but there is no indication what the actual order is in the timeline, no column saying z, nor any other kind of sign saying: hey z-ordering here!

I think the change is good. Top entries == more in front that kind of association is easy to make.

[LearnCocos2D]

a) it's a subjective topic, so there's no right or wrong and both settings make good sense b) we have no data on what the majority of users prefer, or whether the order actually matters that much to them c) there's already a long-established default behavior which should not be changed lightly

That last two points are essential to my argument of leaving the default as it is. It's never a good idea to change the default behavior of a live app for everyone when you can just introduce the new way as an option (unless it's something that pretty much violates everyone's expectation).

As an option to override the default, such a change happens without any friction whatsoever, and makes those users happy who prefer the new behavior and then find out this option exists, while everyone else won't even take notice.

As of now, this change will confuse and even aggravate an unknown (but certainly not insignificant) number of existing users, while the other group gets something they take for granted or may not even care much about. Still, both groups will experience an unexpected change of an essential aspect of the editor, and both groups have no knowledge about this change happening, or why!

Even the group who will ultimately like the change will be confused initially. Take this for example, groups of numbered nodes which don't overlap in the current document, but their order matters in the document where the nodes are included:

"Huh, that's odd. Why are my nodes numbered backwards now? Let me drag them back to their original order ..."

30 minutes later the user complains on the forum that some nodes disappeared, or background elements overlap the menu, or something like that.

In summary: It would have sufficed to offer the new way as an option, rather than changing the default behavior for everyone, whether they want to or not. Even users who would ultimately want the change are not aware of it (not mentioned in the App Store log) and may mistake it for something else.

On top of that it voids a significant portion of existing documentation. For that reason alone the old behavior ought to be reverted as the default asap. Also there's at least some evidence in support that the old ordering wasn't really wrong or unusual per se, several 2D tools use that order (I know for sure: Unity GUI canvas, Spine, CocoStudio, LevelHelper, Gumbo for Corona SDK, Clickteam Fusion, Overlap2D for libgdx - only exception I'm aware of: Construct 2).

[collidernyc]

OK - I've been thinking about this a lot since I first brought it up and it was changed. Iv'e been busy with work stuff, so sorry it's taken so long to throw my 2 cents in the hat. I don't fully disagree with Steffen - maybe as is there should be a preference. But this brings up a much bigger question, one I hadn't fully thought through when I suggested the draw order be reversed. Unity2D's Hierarchy tab is hierarchical only for parent/child relationships, not drawing order, (I'm not talking about the UI system yet, @LearnCocos2D ). Sprites are drawn by default first in = lowest order. I can move my objects in the hierarchy wherever I want and that has no effect on the visual hierarchy. You need to add them to a Sorting Layer and set the Order in Layer to set the visual hierarchy (exactly the same as Cocos zOrder, but there is no visual SB way to set this). SB has no concept of a Sorting Layer, though CC2D does have a zOrder, so this type of concept would work.



But this brings up the point: There is no real separation of visual vs. hierarchal in SB. This is compounded by the mixing of the Timeline (After Effects-like/visual) and sorting (should be Unity or programming-like) metaphors. Unity does it by giving control over user created layers and user created sorting layers. Since SB is a visual tool, I think the visual metaphor should take precedence, but we should also have control over z-order. Once you add user controlled zOrder, the hierarchal visual representation goes out the window. So that's why Unity does what it does... I'm not really sure what the correct answer is here. Cocos 2D has the same basic structure and concepts as Unity. I would be way more receptive to the original hierarchy if there was a Layer and ZOrder concept that worked. Does something along these lines grab anybody? If 2 layers are set to the same sorting layer, they default to the hierarchy.

As far as Unity UI goes... they're getting a lot of flack from users for the same reasons SB is... the representation on zOrder in UI is inconsistent from the representation set up in the overall program.

[LearnCocos2D]

Just to add to this:

I found that 2D game tools with hierarchical scene graph all seem to be using the "topmost is backmost" ordering as it pertains to the draw order, whereas 2D tools including art programs with a flat hierarchy (simple list of layers) prefer the "topmost is frontmost" ordering.

And then there are several game tools like Unity (except for GUI canvas) which use a hierarchical scene graph but do not make the draw order depend on the hierarchy at all. Which implies a separate rendering step that sorts nodes based on their draw order, a step that seems typical for 3D engines but most "true" 2D engines try to avoid.

There is definitely no right or wrong here, it is a highly subjective topic, and certain approaches depend on support by the underlying renderer and I believe 3D renderers generally take a different approach than 2D renderers.

That said, I don't think that we need a "layer" concept like in Unity exactly because you can make any node a "layer" and switch draw order of layers easily by moving them above or below another "layer" node in the hierarchy. Unity needs those layers because its draw order is completely unaffected by the hierarchy.

[NickyWeber]

I really suggest to add something to show the direction of z-ordering currently set, whether another column with the values or other helping visuals.

[LearnCocos2D]

The question is: what are the use cases for manually changing zOrder in SpriteBuilder where changing the order via timeline hierarchy is at least cumbersome, if not insufficient?

The only real use case I can think of atm is where you want child nodes to be drawn behind the parent. I believe cocos2d draws parent-children in this order:

• draw children with negative zOrder
• draw parent (regardless of its zOrder)
• draw children with positive zOrder (including 0)

So if this is true there's currently no way to have child nodes be drawn behind their parent. Question is: maybe it suffices to flag some nodes as to be drawn behind their parent node? Of course there's always the workaround of adding these nodes to a different parent, and if necessary adding all of these parents to a common parent.

Because once you start allowing full zOrder editing the hierarchy is no longer necessarily representing the draw order, and I'm afraid that for most users this will only add to confusion.

[slembcke]

@LearnCocos2D I have sometimes wanted to be able to set negative, or other specific zOrder values. For example, set all sprites to be z=5 and particle effects z=6. Though I agree that exposing it in the UI would be more confusing than useful and have been happy to just handle it in code instead.

That said, I don't think that we need a "layer" concept like in Unity exactly

We actually have it already, it's just not exposed outside of the CCRenderer API yet. ;)