[devel] sprite positioning regarding it's parent

cocos2d for iPhone » Programming » cocos2d internals

[devel] sprite positioning regarding it's parent

(32 posts) (11 voices)

Started 2 years ago by riq
Latest reply from crmagicxxx

Tags:

12 Next »

riq
Key Master

Issue:
http://code.google.com/p/cocos2d-iphone/issues/detail?id=667

I would like to discuss what would be the expected position of an sprite when it is parented to another sprite. Please, don't take into account the current behavior.

Example:
Sprite A is positioned at (100,100), and it has an anchor point of (0.5, 0.5)
Sprite B is a child of A, and has an anchor point of (0.5, 0.5).

If the position of B is (0,0), where do you expect it to be placed ?

I expect that the world coordinate of B would be (100,100), the same of it's parent.
I expect that B's position to be relative to the parent's anchor point.

What do you think ? Should the parent's anchor point be taken into account ? ideas ?

In cocos2d-python we solved it by adding the "children-anchor-point" property. It is a possibility, but I'm not convinced about it.

Does anyone know how CoreAnimation's Layer work regarding this issue ? It has children and anchor point, but I don't know how they are placed.

Posted 2 years ago #
crmagicxxx
Member

I think (0,0) of the B should be exactly at the anchorPoint of A, so yes, from your example world coordinate (100,100) seems logical to me

Posted 2 years ago #
slipster216
Moderator

I would expect the same.. If you need to create something more complex, put a cocosnode between the two and do your offsets with that; no need to litter the code with extra stuff for edge cases.

Posted 2 years ago #
badawe
Member

Exactly @crmagicxxx just like Flash, lets think like that:

You have one Sprite at position (200x200) in world. And his children is on (0,0) relative to Sprite, so this Sprite (children) must be at 200x200 of world, and if you move this sprite in to position(30,30) at world he must stay in (230x230)
This make a lot of sense to me!

Posted 2 years ago #
nsxdavid
Member

@riq

Yes, B and A should be coincident. I'm not even sure what a logical alternative would be. But yes, relative to the anchor point.

-- David

Posted 2 years ago #
riq
Key Master

Thanks for the feedback.

In cocos2d v0.9-beta:

1) When the sprites (grandchildren) are rendered using an SpriteSheet then, the children are positioned as expected, relative to A's anchor point.

2) But, if the sprites (grandchildren) are rendered using a node (not using SpriteSheet) then the position of the B won't be relative to A's anchor point. Instead B will take as the "pivoting point" the point that would be used if A's anchor point would be (0,0).
(If this sentence doesn't make sense in English, please let me know, I'll try to explain it better)

So, with 1), if you move A's anchor point, then B will move too.
With 2), if you move A's anchor point, B won't move at all.

As you can see 1) and 2) behaves differently. And you have mentioned in this post, I, too, agree that 1) should be the expected behavior.

So my idea is to change the current behavior of normal sprites, so the they behave like the Spritesheet's sprites.

If someone doesn't agree with it, please let me know ASAP, and let's discuss it.
Probably I'll implement this feature this week or the next one.

Posted 2 years ago #
crmagicxxx
Member

Ok I now got your point with 2) and it makes sense that someone maybe want to move anchorPoint of the parent without actually affecting children's position. Can you maybe integrate something like honorAnchorPoint like you have it for transformations? Default behavior would be YES but someone can change it to NO if he likes to change anchor of the parent...

Posted 2 years ago #
mobilebros
Moderator

I agree with this change, I usually find myself "correcting" this behavior to go off the anchor point, however this would be a large change, breaking things without erroring.... perhaps like crmagicxxx said with an boolean property, but there's arguments against that too... I vote go ahead with the change in any case.

Posted 2 years ago #
CJ
Moderator

Well this is how Flash handles things:
1. There is no "anchor point" All rotation occurs around the sprite's 0,0
2. If you want it to look like it's center registered (like anchorpoint at 0.5,0.5) you just offset the contents inside to move the center of your content under the 0,0 point.
3. The only time the concept of registration point exists is in the visual IDE where when you change it, it automatically shifts the inner contents for you by offsetting positions while keeping the sprite effectively in the same place.
4. Translating/rotating a sprite that contains children actually translates the coordinate system of that sprite so that children are unaware of any translation/rotation themselves. This means if you have parent set to 50,50 and child is at 100,100 then move parent to 100,100 child remains at 100,100 but appears at 150,150 in world space.

My two cents. I am certainly comfortable working with the Flash style system, and I'm sure there are 1000x more flash developers than Cocos2D developers, so the closer cocos is to flash probably the better. (and cocos being bottom-left oriented vs flash's top-left orientation is no big deal I think)

Posted 2 years ago #
riq
Key Master
A picture is worth a thousand words:

The parent sprite is the one that faces you.
The other 3 sprites, the ones that are facing backwards, are children of it. It's positions are:
```
[child1 setPosition:ccp(20,30)];
[child2 setPosition:ccp(-20,30)];
[child3 setPosition:ccp(0,0)];
[child3 setScale:0.5f];
```
Using cocos2d v0.9-beta
The anchorPoints from left to right are: (0,0), (0.5,0.5) and (1,1)
The green point is the anchor point of the parent sprite.

A) Using SpriteSheet

B) Using Sprite

A) The children are relative to the parent's anchor point.
B) The children are relative to the parent's bottom-left corner.

Both have pros and cons.

Thinking of this issue again, what I don't like about A) is:
- I've forgotten that if you move the anchor point of any sprite, then that sprite will "move".
So if you move the parent's anchor point, then the parent sprite will "move", but not it's children because they are relative to the parent's anchor point. This means that parent and children will "move away" if you move the parent's anchor point.

B) is not so bad, but I don't like that the origin is always the bottom-left corner.

So, having a childrenAnchorPoint is not a bad idea after all.

What do you think about it ?
Posted 2 years ago #
riq
Key Master

... and by childrenAnchorPoint I meant point used as the "born" point of the children.
Perhaps childrenAnchorPoint is confusing, since it's not the children's anchor point, but the "born" point.

If you agree with the childrenAnchorPoint feature, what name do you suggest for it ?

Posted 2 years ago #
riq
Key Master

and if childrenAnchorPoint (or childrenStartPoint or childrenBornPoint...) is added, then the property relativeAnchorPoint could be removed.

For example, by default the childrenAnchorPoint of the Layers would be (0,0) while in the Sprites it would be (0.5, 0.5).

regarding backwards compatibility, setting the Sprites' childrenAnchorPoint to (0,0) would behave as in v0.8.x

@CJ: regarding Flash, actually cocos2d doesn't follow the Flash API, and it is not it's intention to do it. However if some features of Flash or any other framework (CoreAnimation, pygame, unity, Torque, etc...) are useful, I won't mind in implementing. But I think this is not the case, since flash doesn't support AnchorPoint, and this feature in particular is very specific to anchor point.

Posted 2 years ago #
riq
Key Master
SVN r1640 works as "expected".
Both Sprite and SpriteSheet render the same thing. I've added many many sprite tests.

The default childrenAnchorPoint for sprites is (0.5, 0.5).

If your game uses compound sprites (a parent sprite with children sprites) you can do:
```
// compatibility mode with v0.8. Only needed if you are using compound sprites.
parent.childrenAnchorPoint = ccp(0,0);
```
Posted 2 years ago #
riq
Key Master
To make v0.9 compatible with v0.8, and also to prevent confusion, the default childrenAnchorPoint will be (0,0).

You can override it easily with:
```
sprite.childrenAnchorPoint = ccp(0.5f, 0.5f);
```
r1657
Posted 2 years ago #
CJ
Moderator

@riq no problem. I wasn't suggesting implementing anything like a Flash API. I was just saying that one of the most popular graphics programming APIs around doesn't have the concept of an anchorpoint at all and developers cope just fine. Perhaps it is easier to strip this whole anchorpoint concept from Cocos2D to simplify things. No need to respond further on this point unless you agree or are interested in further discussion :)

Posted 2 years ago #
riq
Key Master

@CJ: thanks for the feedback, but anchorPoint, as I see it, is a very important concept. But Popular API != well designed API.

update: What I'm saying is that I don't want to discuss features based in how popular an API is. I prefer to discuss features based on how well designed is the API.

Posted 2 years ago #
riq
Key Master

And to prevent confusion between anchorPoint and childrenAnchorPoint (they are 2 different things with similar names), I've just renamed childrenAnchorPoint to childrenBornPoint.

r1664

Posted 2 years ago #
Codemattic
Moderator

IMHO the only thing that should have an anchor point are the initial screen setup and TextureNodes/Sprites. Everything else has an origin and let the programmer/designers work around that. If I draw a node at (x,y) in its parent's coordinate system, then at that point is (0,0) of that node's system. Rotation, scaling, etc is always around the origin (0,0) of the node. Cocos system is IMHO unnecessarily complex - I like Flash's system not bc Flash is popular but bc it makes sense (to me at least.)

I would also consider grouping nodes in to two non-overlapping groups. Nodes that are containers for other objects, and nodes that draw themselves like TextureNodes, Sprites, etc. Things like TextureNodes are still subclasses of CocosNodes, but they cannot have children and throw an error if you try to -addChild:. To me it doesnt make sense to be able to add subnodes to a TextureNode.

Container nodes are basically coordinate systems and obviously their origin is always at (0,0).

DrawingNodes need to define some standard as to where their origins are.

Posted 2 years ago #
slipster216
Moderator

I have to say I'm also not crazy about the idea of childrenBornPoint. It's hard to explain, and using a dummy node works just as well if you want to do complex offsets like that (which, imo, is somewhat rare). I suspect most people would simply use a dummy node before they even realized childrenBornPoint existed.

I also agree with Codemattic that the inheritance of CocosNode is getting somewhat monolithic, but it's not out of control yet. If we were in C++, I'd go the multiple inheritance route and inherit only what is needed for each node from several base classes (likely, CCTrans, CCDraw, CCContainer, etc). Unfortunately that model doesn't work for ObjC.

Posted 2 years ago #
riq
Key Master

Regarding childrenBornPoint, it is rare feature. Nobody needed it yet. The idea is to simplify building "compound sprites". If this feature makes cocos2d slower/bloated/difficult to read the code, I will remove it.
From what I heard, nobody likes it so: If anyone is in favor of this feature, please let me know, otherwise I'll remove it.

regarding anchorPoint, I think it is important feature since it simplify game development and I think it is overkill to create a void node just to have a custom anchor point. Perhaps in Flash+PC is not overkill, but it is in cocos2d+iphone since adding extra nodes to the scene graph is expensive: about 4 or 5 GL calls per extra node, and the maximum depth in in scene graph is 16 (hardware limitation).

regarding TextureNode it is somewhat deprecated in v0.9. The only one using it is Label since Sprite uses it's own way to draw textures. I might merge into Label in the near future.

[update]:
Label could be a sublcass of Sprite
Another node that is on the "will be removed soon" list, is AtlasNode. Instead of subclassing AtlasNode nodes can simply add TextureAtlas as an ivar

Posted 2 years ago #
slipster216
Moderator

Given the depth limit I can now see why you were thinking of having a born point. In a complex case you could easily push 16 levels deep. However, I still view that as an optimization case and think the framework should be kept simple. If someone is pushing 16 levels deep with a complex scene/character, they can always write code to do that offsetting themselves, and might have to anyway given a really complex case.

Posted 2 years ago #
riq
Key Master
Update:
v0.9.0-beta2 (r1678) doesn't include the childrenBornPoint feature.
If anyone is interested in using it, it is here:
http://code.google.com/p/cocos2d-iphone/source/browse/#svn/branches/branch-0.9-childrenBornPoint

@slipster216: Did you mean anchorPoint ?
childrenBornPoint was just a feature for lazy programmers.

Example of using the childrenAnchorPoint (removed feature):
```
CCSprite *parent = [CCSprite spriteWithSpriteFrameName:@"parent.png"];
parent.childrenBornPoint = ccp(0.5f, 0.5f); // children will be born at the center of this sprite

CCSprite *child = [CCSprite spriteWithSpriteFrameName:@"child.png"];
child.position = ccp( 0,0);  // (0,0) is relative to the center of it's parent.

[parent addChild:child];
```
Same behavior without childrenBornPoint:
```
CCSprite *parent = [CCSprite spriteWithSpriteFrameName:@"parent.png"];
CGSize parentSize = [parent contentSize];

CCSprite *child = [CCSprite spriteWithSpriteFrameName:@"child.png"];
child.position = ccp( parentSize.width/2, parentSize.height/2);

[parent addChild:child];
```
So, the more I think about it, the more I think it is not an useful feature.
Probably I didn't explain it correctly (and probably I misunderstood the original bug too, the bug I opened... ha).

Thanks for the feedback!

@all:
Feel free to discuss any feature/implementation of cocos2d. We might agree or not but discussing features is part of healthy development process.
Posted 2 years ago #
georgeburns
Member
Darn... kind of liked the children born point.

"childrenBornPoint was just a feature for lazy programmers."

I guess I'm one of the lazy ones... but aren't a lot of IDE features for lazy (efficient) programmers? Under the lazy logic wouldn't we just get rid of all convenience constructors too? What about default class state values? I don't see anything wrong with being lazy.

In the case I just converted to .99... I have some pretty hefty equations in position statements now. It's not that hard, but now the code is not easy to understand anymore. I'm dealing with a lot of sub-sprites with exact positioning relative to their parents.

For example before:
```
CGSize parentSize = [octopus contentSize];
octupus.childrenBornPoint = ccp(parentSize.width/2,parentSize.Height/2-30)  //offset
shoe1.position = ccp(-50,0);
shoe2.position = ccp(-40,0);
shoe3.position = ccp(-30,0);
```
etc...

now....
```
CGSize parentSize = [octopus contentSize];
shoe1.position = ccp(parentSize.width / 2 - 50,  parentsize.height /2 - 30);
shoe2.position = ccp(parentSize.width / 2 - 40,  parentsize.height /2 - 30);
shoe3.position = ccp(parentSize.width / 2 - 30,  parentsize.height /2 - 30);
```
It's not that difficult... but it was sure nice the other way.

Just my thoughts.
Posted 2 years ago #

riq
Key Master

@georgeburns: thanks for the feedback.
The bornChildrenAnchorPoint was adding complexity to cocos2d (it was making it a little bit slower too) for a feature that can be implemented with a an add.

You can rewrite your code as:

CGSize parentSize  = [octopus contentSize];
CGPoint center = ccp( parentSize.width/2, parentSize.height/2);

shoe1.position = ccpAdd( center, ccp(-50,-30) );
shoe2.position = ccpAdd( center, ccp(-30,-30) );
shoe3.position = ccpAdd( center, ccp(-20,-30) );

Posted 2 years ago #

georgeburns
Member

Thanks for the tip... that cleaned it up a lot.

Posted 2 years ago #
vargonian
Member

I just ran into this issue and it's really counter-intuitive. I agree with nsxdavid and many of the other commenters. I would completely expect that a child sprite (for example) added to a parent should be positioned relative to its parent's anchorpoint.

It's not a matter of laziness; it's a matter of having an API that is intuitive, consistent, and doesn't require unnecessary coding to achieve your goals. As a silly example, imagine if the engine automatically rotated all added sprites by 27.139 degrees clockwise. We'd complain that we had to rotate them all back. Would this make us "lazy"? Of course not.

The biggest potential issue I've heard talked about so far with this implementation is the fact that, if you move the parent's anchorpoint, it will affect the position of the child sprites. 1) How is this a problem? and further 2) Wouldn't this, in most cases, be exactly what you desire?

Rather than making everyone, in the common case of adding child sprites relative to the parent, have to perform the computation required to position a child relative to the counter-intuitive bottom-left corner of the parent, why not put the computational burden on the (extremely uncommon?) case of people who want to change a parent's anchorpoint after-the-fact without affecting the children?

Does anyone have any issues with this?

Posted 1 year ago #
riq
Key Master
@vargonian:
This feature was actually implemented ( http://code.google.com/p/cocos2d-iphone/source/browse/#svn/branches/branch-0.9-childrenBornPoint ) but I later decided to remove it because:
- it was making the code slower
- it was making the code more difficult to maintain

cocos2d tries to provide an easy to use API, and perhaps in this particular case the user needs to add 2 or 3 lines of code to achieve what you want (perhaps a macro could be used instead). Perhaps cocos2d could provide such macro. Are you interested in coding it ? I'll add it in the next release.

eg:
```
id parent = [CCSprite ....];
 id child = [CCSprite ....];
[parent addChild:child];
CC_POSITION_RELATIVE_TO_PARENTS_ANCHOR_POINT( child, ccp(-20,40) );
```
Regarding the anchorPoint:
If you modify the anchorPoint of any sprite, that sprite will move, and in consequence, all its children will move too. What would be the expected behavior for you ?
Posted 1 year ago #
vargonian
Member

If there are good reasons to keep it the way it is, that's fine and I can work with it. I think it needs to be spelled out clearly in the docs, though, because I don't think it's the behavior that most people would expect (based on experience with typical scenegraph hierarchies).

Oh and regarding the macro, I tend to stray away from macros but if it's a popular feature, I'll consider it.

Posted 1 year ago #
riq
Key Master
@vargonian:
I remember the bug regarding the anchorPoint.
It's difficult to explain without images, but here it goes:
```
What's anchorPoint ? (from the Doxygen strings)
/** anchorPoint is the point around which all transformations and positioning manipulations take place.
 It's like a pin in the node where it is "attached" to its parent.
 The anchorPoint is normalized, like a percentage. (0,0) means the bottom-left corner and (1,1) means the top-right corner.
 But you can use values higher than (1,1) and lower than (0,0) too.
 The default anchorPoint is (0.5,0.5), so it starts in the center of the node.
*/
```
Example:

P: parent
C: child

P.position = 100,100
C.position = 0,0

If C is relative to P's anchorPoint, then:

if P's anchorPoint is (0,0) then:
C will be positioned on P's bottom-left corner
C absolute position will be 100,100

If you decide to change the anchorPoint in runtime (it's a possible scenario), to, let's say (1,1) then:
C will be re-positioned on P's top-right corner
But C absolute position will still be 100,100. It's like if C's position wouldn't have changed!

And IMHO, this is not the expected behavior. If you move P's anchorPoint, P will move, and C should move accordingly.
Posted 1 year ago #
davecom
Member

Riq, thanks for the explanation of the anchor point - very helpful. Coming from Java drawing, I do prefer to deal with the bottom left or top left hand corner in everything - but that is probably more of a learned behavior than a best practice. I appreciate the clarity of this explanation and I believe the concept of an anchor point allows for more powerful transformations more easily. I also respect the fact that moving the default anchor point would break backwards compatibility for many games. Therefore I think your design decisions are completely sound.

Posted 1 year ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.