Normalised node placement breaks with children.

[Birkemose]

Placing a normalised node on anything but the base node, results in wrong node placement. It seems that internally the node positioning is changed from representing coordinates into the viewport, to representing normalised coordinates, which obviously will not work with consecutive transformations.

The correct way to do this, must be to make ex. normalised transformations in the property implementation.

[vlidholt]

I am pretty sure this works as intended. The normalized position is relative to the size of the parent's container. E.g. if you place a node with a normalized position of 0.5, 0.5 it will always appear at the center of the parent node.

[slembcke]

I talked with Birkemose a little earlier today. I think the confusion was just that it was expected that normalized coordinates were relative to the viewport and not the parent node (which had a contentSize of 0).

edit: Had it backwards.

[Birkemose]

Yes, the problem for me was, that I didn't realise that a normalised position was not relative to viewport, but to parent. Which probably is fine. My bad.

My point about this being a potential problem, is still valid though. People using cocos2d "the old way", will add a node to a scene, and group some components on this node. The new normalised placement type is cool, so people will want to use it. If they do, it will not work.

The first though that springs to mind, is default applying the viewport as contentSize to an empty node, but it also doesn't cling as a right solution. Then we are back to a CCLayer, which we just deprecated. I know setting the content size manually, will fix it, but 100.000 newcomers will not.

Any suggestions?

[slembcke]

Hmm. What if we have an warning that tells you if you are using the normalized type when you have a parent with a contentSize of 0.

Maybe an assertion should be better? There really isn't a good reason to ever use normalized with a sizeless parent. Assertions are much harder to ignore than warnings. ;)

I'm a fan of libraries that tell you when and how you are using them wrong.

[Birkemose]

Yeah, a meaningful assertion will fix this I think.

[vlidholt]

I think adding an assertion may break SpriteBuilder, please don't add it without testing it with SpriteBuilder.

[cocojoe]

I assume I ran into the same situation, I changed self contentType to Normalised (1,1) then added a physics node to enable physics. I presumed that this would mean my physics world was also normalised (1,1) for any subsequent nodes. However it did not work out that way.

Normalised placement is a great feature, it makes my universal tutorial so much cleaner, if it worked as expected?

I'm currently writing tutorials and looking at things from a new user perspective, in particular when we require extra steps vs SpriteKit.

[Birkemose]

I am also a big fan of a normalised space. So much that I mentioned it in my first roadmap. If we could solve this gracefully, it would be a big win-win.

[vlidholt]

I found a bug related to this, if you change the content size of a node after you have set its child's position the position isn't updated. This will need to happen. I will do a bug fix for that!

[slembcke]

@vlidholt Andy made some unit tests that are pretty close to what you described. Should make sure that issue is covered for future testing too.