cocos2d for iPhone

A fast, easy to use, free, and community supported 2D game engine

1. 

   georgejcook
   Member

   Does code exist to get the contentsize of a sprite/node that contains other nodes?
   e.g. if I have
   backgroundContainer
   and it contains background
   background has size w/h100
   I set background.scale to 2
   if I ask background it's contentSize.width/height I get 200
   if I ask backgroundContainer I get 0.

   If this hasn't been implemented, should I implement it and post it back here so it can be incorporated into cocos2d? If so, what should it be called? -(ContentSize) contentSizeIncludingChildren ?

   Thanks

   Posted 2 years ago #
2. 

   adunsmoor
   Member

   I posted a class that inherits from CocosNode that automatically updates content size as children are added and removed.

   http://www.cocos2d-iphone.org/forum/topic/688

   All of the information needed to calculate the content size including children is publicly accessible so it really could have been implemented as a function instead of a new class. Perhaps something like:

   CGSize getContentSizeIncludingChildren(CocosNode *root);

   The more I think about it, the more I think the current behavior of sprites/nodes is a bug. It seems to make sense that a node should consider both its own size and the size of its children when reporting content size.

   Good luck.

   Posted 2 years ago #
3. 

   georgejcook
   Member

   thanks, I'll incorporate getContentSizeIncludingChaildren in cocosnode.

   I also think it's an oversight, but probably becuase of backward compatability, Riq and others wont be able to change it.. perhaps the helper method getContentSizeIncludngChildren will be the best solution.

   I think this because it'd be best as a getter, as the children can change size, scale and position inside another node, so only doing the calc's on add/remove wont catch all resizing cases.

   This also points to a dual method solution, as it will be a helluvalot less performant, so with 2 methods it can only be used when necessary, with no performance/regression impact on cocos2d.

   In fact, I'll request this as a feature, using your code, if you don't mind :)

   Posted 2 years ago #
4. 

   invulse
   Member

   Has this been overlooked in recent updates? I ran into this issue today and it seems strange that CCNode's contentSize does not include child sizes that are contained within it...The code posted before works very well for me, but I can't see any reason why this is not in Cocos2d by default.

   Posted 2 years ago #
5. 

   CJ
   Moderator

   I think Cocos should have several properties for the following:
   - boundingBox (as it is today, returns axis aligned bounding box of the node, including roation/scale etc...)
   - contentSize (as it is today, returns the object width/height, not considering rotation/scale, children etc...)
   - boundingBoxIncludingChildren (returns axis aligned bounding box of the node, after building up all of the boundingBoxes of its children)
   - contentSizeIncludingChildren (returns width/height, after building up boundingBoxes of its children) [Note that this isn't exactly recursive because it doesn't call contentSizeIncludingChildren on it's children, it instead calls boundingBoxIncludingChildren on them]

   I have this in my hacked version of Cocos2D, so if Riq and others want to comment on the API at all before I submit a patch, go for it :)

   Thanks

   Posted 2 years ago #
6. 

   mmilo
   Member

   BUMP...

   I don't like hacking either, I have to re-insert code after every update.

   Any chance we can see this into core?

   Posted 1 year ago #
7. 

   gaminghorror
   Member

   >>- boundingBox (as it is today, returns axis aligned bounding box of the node, including roation/scale etc...)<<

   I have this in a CCSpriteExtension class, no cocos2d hacking required:
   http://www.learn-cocos2d.com/knowledge-base/cocos2d-iphone-faq/learn-cocos2d-public-content/manual/cocos2d-general/14813-how-to-get-a-sprites-bounding-box-bounding-rectangle-with-code/

   It doesn't take into account rotation because once you can't rotate a CGRect (using the CGRect struct) and even if you could you can't use a rotated Rect with CGRectIntersect and other methods.

   If you mean the smallest possible rect for a rotated sprite (eg the corners of the sprite touching the rect sides with the Rect blown up the most when the rotation is 45°, 135° etc) then i don't think that would be very useful to developers. At least not for collision checks.

   Anyway a lot of this could be added as Objective-C categories but with the downside of having to make the calculations each time the method is called instead of updating that info when it changes.

   Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.