[devel] CCSpriteSheet to support grand children, grand-grand children, etc...

cocos2d for iPhone » Programming » cocos2d internals

[devel] CCSpriteSheet to support grand children, grand-grand children, etc...

(37 posts) (12 voices)

Started 2 years ago by riq
Latest reply from nsxdavid

Tags:

12 Next »

riq
Key Master

Hi,

I'm about to implement issue 346:
http://code.google.com/p/cocos2d-iphone/issues/detail?id=346

Basically you will be able to have a big family (grand-parent, parent, children, grand-children, etc) when using CCSpriteSheet.
For example you will be able to put an energy bar on top of your hero while using CCSpriteSheet

I'm going to implement more or less like this:

The new updatePosition will have more or less this:

// CCSprite#updatePosition
-(void)updatePosition
{
	NSAssert( parentIsSpriteSheet_, @"updatePosition is only valid when CCSprite is using a CCSpriteSheet as parent");

	float newRotation = rotation_;
	float newScale = scale_;
	float newPosition = position_;

	Class aClass = [CCSpriteSheet class];
	for (CCNode *p = parent; p = p.parent) {
                if( [p isKindOfOfClass:aClass] )
			break;
		newRotation += [p rotation];
		newScale *= [p scale];
		newPosition =  ccpAdd( newPosition, [p position]);
	}

	// ... code continues as in v0.9.0-alpha
	//
}

and the addChild, removeChild, reorderChild both from CCSprite and CCSpriteSheet will be refactored.

What do you think ?

Posted 2 years ago #

vennt
Member

I can't comment on the code (still green, and haven't updated to 0.9 alpha either), but sounds exciting!

Posted 2 years ago #
badawe
Member

Sounds very Good riq! Thats just amazing for some things!

You are georgious!

Posted 2 years ago #
mhussa
Member

Sounds good.

How do you expect the Z ordering to work? will the child Z be relative to the parent? layer? scene?

The reason I ask is that I currently overlay a sprite on top of another to colour it uniquely. At the moment I let the colours mix when they cross-over each other. Its not bad but not great either, would be nice if the Z was handled locally to the parent than in the layer as I have now.

Posted 2 years ago #
riq
Key Master

@mhussa: z ordering will work the same way as it works when the parent is not an CCSpriteSheet

Posted 2 years ago #
nsxdavid
Member

As the guy who created Issue 346... I say...

BRAVO!

cocos2d is spectacular. Despite the success of geoDefense and geoDefense Swarm with my own engine, all new stuff is done in cocos2d. geoSpark, my next game is going into the App Store review process tonight... my first cocos2d game. :)

-- David

Posted 2 years ago #
slipster216
Moderator

@nsxdavid:
ah crap, there goes my productivity again. Any chance of a geoDefence level pack? Also, is it me or did your first update to geoDefence (the original, not swarm) make the game a lot easier? I had one map left to beat and the first update came out, and it *seemed* like everything got a lot easier..

Posted 2 years ago #
onedayitwillmake
Member

Very cool, is it safe to grab this from SVN and implement it.
I've started migrating my project to 9.0, for this reason, but I hadn't noticed until now that this isn't in the 9.0 alpha zip.

I'd like to kill two birds with one stone, thank you :)

Posted 2 years ago #
riq
Key Master

@onedayitwillmake: this feature is not implemented yet (it is not on the SVG) but it will part of v0.9.0-beta.

Posted 2 years ago #
shaunti
Member

I take it this is to cascade all properties AND behaviors to the children.

Or is it just on positioning and drawing with z-ordering?

Like [FadeOut] on the parent causes the children to do so as well I assume.

I actually have a need for this, but I just have to call on every item for now.

Posted 2 years ago #
Karl
Member

Ok, so basically a CCSpriteSheet, while technically a CocosNode, will have its position, rotation, and scaling completely ignored by its children, right?

Posted 2 years ago #
riq
Key Master

@karl: The new CCSpriteSheet will be like a CCNode but it will draw all its "sub" children in just 1 opengl call, and with some limitations like all its "sub" children must have the same texture id.

@shaunti:The behavior will like a the current CCNode.

Posted 2 years ago #

riq
Key Master

the algorithm that I posted was wrong. Rotation was not taken into account.
this algorithm works as expected:

CGAffineTransform old = CGAffineTransformIdentity;
	float newScaleX = 1;
	float newScaleY = 1;

	Class aClass = [CCSpriteSheet class];
	for (CCNode *p = self ; /* ignore */; p = p.parent) {
		if( [p isKindOfClass:aClass] )
			break;

		CGPoint pos = p.position;
		float	rot = p.rotation;
		float	sx = p.scaleX;
		float	sy = p.scaleY;
		CGAffineTransform new = CGAffineTransformIdentity;
		new = CGAffineTransformTranslate(new, pos.x, pos.y);
		new = CGAffineTransformRotate(new, -CC_DEGREES_TO_RADIANS(rot));
		new = CGAffineTransformScale(new, sx, sy);

		old = CGAffineTransformConcat( old, new);
		newScaleX *= [p scaleX];
		newScaleY *= [p scaleY];
	}

	CGPoint newPosition = ccp( old.tx, old.ty);
	float newRotation_radians = -atan2f( old.c, old.a );

Posted 2 years ago #

mobilebros
Moderator

Haha yes, I was going to say it's not a simple += operation when there's rotation involved. I think what you're doing would work nicely. Keep up the great work!

Posted 2 years ago #
nsxdavid
Member

Riq,

It is important to point out that one of the intended use cases was to be able to anchor like a healthbar to a character on screen through parenting. But there needs to be one more feature (not unique to spritesheets) to make this work right...

Namely you need to be able to selectively disable specific propogation of transformations to the children. For example, if you have (like in geoDefense) a situation where characters are rotating on the screen, you don't want an offset child sprite to be the healthbar becaues it would rotate around with its parent. Not the intended result, in this case.

This is sorta like a Ferris Wheel... the whole thing can rotate but you want the individual cars to remain upright.

Locking rotation, translation, or scale independently on any child would allow one to achieve this and other great effects. It is not unique to sprite sheets of course, but rather the whole child/parent thing.

-- David

Posted 2 years ago #
riq
Key Master
@nsxdavid: yes, that could be added as an special case...

r1556 supports any level of descendants (children, grand-children, etc...)
The only missing feature is reorderChild. It is not implemented yet.

I would like to know what kind of API are thinking of for locking rotation, translation, etc...

This API should not be part of spriteSheet since it should work also without it, like in standard nodes.

The API that I have in mind is:
```
CCNode *node = [CCnode node];

// default
node.honorTransform = CC_NODE_HONOR_TRANSFORM_ALL;

// for health bar. Honor all transformations but rotation
node.honorTransform = ~CC_NODE_HONOR_TRANSFORM_ROTATE;

// possible transforms

typedef enum {
  CC_NODE_HONOR_TRANSFORM_TRANSLATE = 1 << 1;
  CC_NODE_HONOR_TRANSFORM_ROTATE = 1 << 2;
  CC_NODE_HONOR_TRANSFORM_SCALE = 1 << 3;

  CC_NODE_HONOR_TRANSFORM_ALL =  CC_NODE_HONOR_TRANSFORM_TRANSLATE | .... | ...;
} ccNodeHonorTransform;
```
What do you think ? Ideas ?
Posted 2 years ago #
mhussa
Member

I have a question, when translate,scale and rotate are mentioned I assume this means the child properties? is this correct?

Are there any plans to add a transformation "origin". If I want a child orb object to rotate around a ship object will this achieve this? or will the orb just rotate around its own anchor? I would want the orb's anchor to be the centre of the ship sprite to rotate correctly.

Posted 2 years ago #
manucorporat
Member

This implementation could be used for a multi-line BitMapFontAtlas.
For example: All items from a menu could be rendered by a single BitMapFontAtlasManager.
Or in a game the scores alerts. +40 Pt

Posted 2 years ago #
manucorporat
Member

@riq: I think that descendants_ and dirtySprites_ should be ccArray. What do you think?

Maybe it does not cause a large increase in performance, but after all ccArray is much faster.

Posted 2 years ago #
riq
Key Master

@manu: For the moment I'm trying to finish the code... after the code is finished, I'll tune the code to go faster.
And yes, there are some places where the code can be improved: using ccArray might improve the code.

Posted 2 years ago #
riq
Key Master

@manu: issue #346 is almost complete. If you have time, could you do some performance tests with ccArray ?
dirtySprites_ is a set instead of an array to prevent adding more than once the same item.
Thanks.

Posted 2 years ago #
riq
Key Master

I did some perf tests:

a) sprite + action: more or less the same performance as v0.8.2
b) spritessheet + actions: in some tests it is between 5% and 15% slower than v0.8.2

b) but it "should" be faster in this test:
- 200 sprites without actions and 100 sprites with actions

revision 1561 is not using anymore the dirtySprites array (which was a set before), and will be converted into a ccArray soon.

Posted 2 years ago #
nsxdavid
Member

@riq Seems like a great API for selective transforms! That'll be quite powerful at a slight cost to performance (to do the IFs).

-- David

Posted 2 years ago #

riq
Key Master

@nsxdavid: Could you try r1564 ?
I've just implemented it.
An working example is on: tests/SpriteTest.m (example #2)

For the moment it only works on CCSprites when they are rendered using CCSpirteSheets.

Example:

//
// How to implement a health bar
//
CCSprite *sprite1 = [[CCSpriteFrameCache sharedSpriteFrameCache] createSpriteWithFrameName:@"grossini_dance_01.png"];
[sprite1 setPosition:ccp( s.width/3, s.height/2)];

CCSprite *sprite2 = [[CCSpriteFrameCache sharedSpriteFrameCache] createSpriteWithFrameName:@"grossini_dance_02.png"];
[sprite2 setPosition:ccp(20,30)];
sprite2.scale = 0.2f;

CCSprite *sprite3 = [[CCSpriteFrameCache sharedSpriteFrameCache] createSpriteWithFrameName:@"grossini_dance_03.png"];
[sprite3 setPosition:ccp(-20,30)];
sprite3.scale = 0.2f;

[sheet addChild:sprite1];
[sprite1 addChild:sprite2 z:-2];
[sprite1 addChild:sprite3 z:2];

// don't rotate with it's parent
sprite2.honorParentTransform &= ~CC_HONOR_PARENT_TRANSFORM_ROTATE;

// don't scale and rotate with it's parent
sprite3.honorParentTransform &= ~(CC_HONOR_PARENT_TRANSFORM_SCALE | CC_HONOR_PARENT_TRANSFORM_ROTATE);

Posted 2 years ago #

DetectiveCakes
Member

That's great Riq! Works well over here, and definitely will be a big time saver for health bars, characters with swappable bits, etc.

Posted 2 years ago #
nsxdavid
Member

@riq

Testing now. Seems to not be honoring ~CC_HONOR_PARENT_SCALE

Testing more to find out if it's my fault or actual bug.

-- David

Posted 2 years ago #
nsxdavid
Member

@riq

Okay, so here's what I have found:

With CC_HONOR_PARENT_SCALE the child sprite will change it's position and scale relative to its parent in the expected manner. If the parent grows 2x then the child will be physically 2x farther away and 2x bigger.

Without CC_HONOR_PARENT_SCALE bit then the child will not change position, but will scale as the parent does. So if the parent gets 2x bigger, the child does too but it doesn't get any farther away. This is not correct. It should not scale at all.

If CC_HONOR_PARENT_TRANSLATE bit is *not* set, the object will be at 0,0 regardless of the child's position setting. One would expect it to not be relative to the parent, but relative to 0,0 and thu (form a position standpoint) be at whatever the child's position is. Of course since in cocos2d everything is relative... I imagine this is relative to the layer?

If honorParentTransform is 0, and the parent is translating, rotating and scaling you'd expect the child to be sitting still at an absolute position (whatever it's position property is set too). Instead it will be at 0,0 and scale with the parent.

-- David

Posted 2 years ago #
riq
Key Master

@nsxdavid:
thanks... yes, I broke it with the last commit.

fixed on r1572

Posted 2 years ago #
nsxdavid
Member

Grabbing

Posted 2 years ago #
nsxdavid
Member

@riq...

Changes in r1572 did not correct the problem. The behavior seems identical. I did verify the diffs against the code i am running.

With:
sprite3.honorParentTransform &= ~(CC_HONOR_PARENT_TRANSFORM_SCALE | CC_HONOR_PARENT_TRANSFORM_ROTATE);

sprite3 will still scale as the parent does, but not scale its relative position.

With:
sprite3.honorParentTransform &= ~(CC_HONOR_PARENT_TRANSFORM_ROTATE);

The sprite will scale and scale its relative position.

Other behaviors described seem to be the same too.

Posted 2 years ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.