@greyhoundgames: No idea :( Try to put some breakpoints to see why it is not called on the device. If you are using id in your code, try to replace it with the the real object:

// replace this code
id action = [RotateBy...];

// with this one:
RotateBy *action = [RotateB...];

just to see any possible compiler warning (and the error). Let's continue talking this issue in another thread.

I will repro it this weekend for you and also include the zorder thing I mentioned 15 or so posts ago if that is still an issue(though this -1 z thing can preclude putting sprites behind each other). While you are around a quick question. I have a ccsprite that is a regular ccsprite with one new function called step which i call from my main loop. It comes from the same atlas/sprite sheet as all the other sprites and is attached to the same parent as some of them are. It works perfectly on the simulator but on the device I cannot see it. Any thoughts?

@greyhoundgames: Can you reproduce it ? If so, could you open a bug on the issue tracker with the code to reproduce it ? thanks.

If you are using cocos2d from SVN I suggest subscribing to the "SVN feeds":
http://code.google.com/p/cocos2d-iphone/feeds

You will receive information about each commit, so you can decide whether or not to do an SVN update.

I am back to my previous post about child order and atlas indexes of 4123412323. I don't have a good code sample yet because this is very buried in my code, but looking at the logic in CCSprite for nesting nodes I am fairly sure I see the problem. I haven't updated my trunk in a week or so, so this may have been fixed but ill elaborate on the problem and you can give me your thoughts.

If you look at CCSpriteSheet,
-(NSUInteger)atlasIndexForChild:(CCSprite*)sprite atZ:(int)z
For a newly added sprite it will be the 0th child. So take the example of where the first thing on the atlas before you add this, is the guy who USED to be 0th child before your guy was added to the parent.
It will go down the childIndex==0 branch because the new guy we are adding is at the front of the children list. I am trying to add this guy behind everybody else so -1 z, means we go down this branch:
if( z < 0 && [brothers count] > 1 )
{
return [self lowestAtlasIndexInChild:next] -1;
}

That function takes our next(child at index 1) and takes his atlas index -1. However he is currently # 0 in the atlas index so that gives us -1. This function deals with unsigned ints and so you end up with max int.

If you don't think this is a correct analaysis let me know and I will try to create this as a stand alone entitiy for verification.
P.S Has much changed since about 2 weeks ago on the trunk? I want to do an update but only if there are some important fixes.

@badawe:

-(void) addSpriteFrame:(CCSpriteFrame*)frame name:(NSString*)frameName;

@riq one question.

I using zwoptex to mostly of my sprites, but sometimes i want o use some sprites normal, can i add to the sharedTextureCash my image? or for this case i must create a CCSpriteSheet for my image?

@Vexorg if you are using svn trunk, you get this errors, and keep working with 0.9 alpha, and works like a charm.

I get a lot of linking errors when trying to use the compatibility mode. This was from a newly created cocos2d chipmunk template and then I imported my files from another project. The only fix seems to be to manual change the names of everything with the CC namespace.

".objc_class_name_AtlasSprite", referenced from:

".objc_class_name_EaseIn", referenced from:

".objc_class_name_FadeIn", referenced from:

".objc_class_name_PageTurnTransition", referenced from:

".objc_class_name_Sequence", referenced from:

".objc_class_name_StopGrid", referenced from:

@riq any change to cocos2d have an option to show actual texture Memory being used in Cocos2d?

like that:

// code from here: http://developers.enormego.com/view/iphone_sdk_available_memory
+(double) getAvailableBytes
{
	vm_statistics_data_t vmStats;
	mach_msg_type_number_t infoCount = HOST_VM_INFO_COUNT;
	kern_return_t kernReturn = host_statistics(mach_host_self(), HOST_VM_INFO, (host_info_t)&vmStats, &infoCount);

	if (kernReturn != KERN_SUCCESS)
	{
		return NSNotFound;
	}

	return (vm_page_size * vmStats.free_count);
}

+(double) getAvailableKiloBytes
{
	return [Utilities getAvailableBytes] / 1024.0;
}

+(double) getAvailableMegaBytes
{
	return [Utilities getAvailableKiloBytes] / 1024.0;
}

//Something like:
[[CCDirector sharedDirector] setDisplayMemoryUsed:YES];

@riq thanks, and sorry about that, i don't even checked if this issue already open.

@badawe:
Yes, anchorPoint with Zwoptex is still not working OK when the anchorPoint is not 0.5:
http://code.google.com/p/cocos2d-iphone/issues/detail?id=653

@riq sorry! Its my bad! i using zwoptex and when i try change the anchor point, i get the problem because offset zwoptex applies, but just untrinn the images, and everything work again.

Maybe the anchor point in someway count the xoffset and yoffset to the calculations? This will be very nice!

@badawe: Sorry, I don't understand the problem. Could you explain it further ? Thanks.

@riq seens the anchorpoint for ccsprite now works diferent? Right? i try make one test with box2d and new 0.9alpha cocos2d, and i can change the anchorpoint of one CCSprite! =/

@greyhoundgames: Could you reproduce it with the latest SVN revision ?
If so, could you open an issue ? Thanks.

Now that I got around that problem I noticed that the z Order of children that is set is not respected. Pos or neg the child appears to always be drawn behind the parent. Looking at the code, the first child of a ccsprite is given its parent's atlas index with the z passed in value ignored. But I also see that you are reording them when the actuall addCHild happens so that may be ok. Based on how I think this is working, the atlas is containing basically a big sorted list of sprites based on render order.

I believe this is all the relevant code. I did some debugging and I determined that its because I am adding children before the parent is added to the sprite sheet. Is this expected? Should we be able to prebuild our entire node(with children) before adding it? Anyhow adding first then doing this made it come back with a 0 for the index

//Scene Node init relevant parts
CCSpriteSheet* thingsSpriteSheet=[CCSpriteSheet spriteSheetWithFile:@"unit_sheet_real.png" capacity:1];
[self addChild:thingsSpriteSheet z:THINGS_Z tag:ThingsSpriteSheet];

//Then later when I actually want to add the units to the screen
CCSpriteSheet *thingsSpriteSheet = (CCSpriteSheet*) [self getChildByTag:ThingsSpriteSheet];
UnitNode *newUnit=[[UnitNode alloc] autorelease];//no init, init happens on next line
[thingsSpriteSheet initSprite:newUnit rect:CGRectMake(0,0,0,0)];
[newUnit setEnemy:enemy];
enemy->unitRenderer=newUnit;
[thingsSpriteSheet addChild:newUnit z:BASE_ENEMY_Z+[newUnit calculateZ]];

//And then shortly after that, the following happens. This is where it has the assert error, trying to add the children nodes

-(void)addBodyParts
{
AnimatedSequenceChildNode* temp=[self setupAnimatedSequenceChildNodeWithRect:CGRectMake(0,0,10,10)];
[self addChild:temp z:1 tag:NodeType_Leg];
[temp addChild:[self setupAnimatedSequenceChildNodeWithRect:CGRectMake(0,0,15,15)] z:2 tag:NodeType_Foot];
}

//helper function
-(AnimatedSequenceChildNode*)setupAnimatedSequenceChildNodeWithRect:(CGRect)rect
{
AnimatedSequenceChildNode *child=[[AnimatedSequenceChildNode alloc] autorelease];//no init, init happens on next line
[self.spriteSheet initSprite:child rect:rect];
return child;
}

@greyhoundgames: Could you post the code to reproduce it ?

@DonomaGames: Yes, it's bug. I'm working on it. SVN r1585 contains an improvement but it is not 100% fixed yet. I've been working on this bug all the day, but today it wasn't a very productive day for me :-(

Trying out the new atlas sprites can be children of other atlas sprites from the trunk(downloaded dec 1st) I encountered the following. Perhaps I am just not doing this right but anyhow.

I alloc an instance of my custom subclass of CCSprite but I do not init it. I then call [spriteSheet initSprite:mySprite rect:CGRectMake(0,0,0,0)]; I used a size 0 rect because I wanted this guy to only represent position for the child\parent hierachy but not render. But I wanted him to be an sprite on the spritesheet so I could get the batch rendering still

It then gets added to the sprite sheet as a child(the sprite sheet is added to the scene).
Then shortly after that I add a child doing the same thing as before but using a actual rect to some image on my sheet. I then add that child to my first node.

When I do this I get an issue because the imageIndex it computes for my sprite is like 412123213123 and this blows up on an assert.

Did I miss something on how this works?

@slipster216

Yes I know. But it's overriding my anchor point. I set all my sprites to ccp(1.0, 1.0) and it's resetting it every frame to ccp(0.5+offsetX, 0.5+offsetY).

@DonomaGames:

This might be because the new format supports the zwopple offsets automatically. You don't need to update the anchor point for each frame of the animation anymore; the offsets stored in the new sprite system do that for you automatically.

@DonomaGames: yes, a sample code will help a lot. thanks.

Thanks for the quick reply. Actually I think this might be a new issue. 8.2 didn't support zwoptex natively and I didn't use zwoptex in 8.2. I didn't specify that clearly in my original post.

I'll see if I can put together some sample code to demonstrate.

@donomaGames: So, it worked OK with v0.8.2 ? but after upgrading it's not working as expected, right ?

Could you open an issue, and if possible, with the code and the images to reproduce it ? thanks

Hi Riq,

I upgraded to the trunk from 8.2 and noticed that this line in CCSprite.m in the setDisplayFrame method is giving me a problem.

anchorPoint_ = ccp( (- frame.offset.x / frame.rect.size.width) + 0.5f,
					   ( - frame.offset.y / frame.rect.size.height) + 0.5f );

It's basically updating the anchor point for every frame and overriding the anchor point that I've set for the sprite. So when not animated, my sprite is positioned correctly. But as soon as it starts animating, the sprite is now off centered. I know the anchor point has to be set b/c each frame could have a different offset, but is this a bug or is there another way to make the animation respect the original anchor point?

thanks

[edit]
I am using a spritesheet where the offset is none 0.

I don't know if this is because I am doing something wrong, but when creating a CCSprite from a file directly, I am able to visit it to cause it to render on a RendereSurface. However that same sprite created from a sprite sheet(though not added to it) does not appear to render (all other things being the same with the previous scenario). In both cases there was no parent object.
Any ideas?

I actually managed to port it in a matter of hour without even using CC_COMPATABILITY_WITH_0_8 flag ;)

my biggest problem was actually not with Cocos2d but with new Box2D and the b2_dynamicBody flag that needs to be added to the body definition if it is to move...

other than that - smooth as butter really

actually this is one of the best things about cocos2d - switching to newer versions requires really little work

@paulhart: cool. Feel free to add a link to your post in the wiki page, in the section that says: "add your experience here"

I just posted my experience with the 0.8.2 to 0.9.0-alpha upgrade on my blog. Was pretty simple.

Yes. The use of CCSpriteFrameCache is optional, but it facilitates the creation.

Take a look at the CCSprite API:
http://www.cocos2d-iphone.org/api-ref/0.9.0-alpha/interface_c_c_sprite.html

You will see the different ways to create an sprite.