I've gotten confused now. Is rc0 or beta2 the latest version? This is sticky'd, but rc0 seems to have a later date?

Anyone know the state of 1.1? I would like my app to have support for the iPad 3. Is the current build stable enough for an app store release?

Funny enough I was having same issue today with the repeatforever, it's true it makes sense to not stop the action, but took me a while to find out!

Hi,
I just upgraded from 1.01 to 1.1b2 to get iPad 3 retina support. For now, though, I don't have all the ipadhd artwork done, so I hoped it would fallback to -ipad, like it does for the iPhone.
However it doesn't. I checked "fullPathFromRelativePath" and found that no fallback is implemented here, so I added

if( CC_CONTENT_SCALE_FACTOR() == 2 ) {
  ret = [self getPath:fullpath forSuffix:__suffixiPadRetinaDisplay];
  *resolutionType = kCCResolutioniPadRetinaDisplay;

  // fallback to non-hd ipad
  if (!ret) {
    ret = [self getPath:fullpath forSuffix:__suffixiPad];
    *resolutionType = kCCResolutioniPad;
  }
}

The normal iPad graphics is loaded and resolution param is set accordingly then, however it still does not do the trick. Graphics are still 50% too small. What am I missing?

Thx, rombos

@cocojoe,

You're right, all previous animation actions on a node should be stopped before running a new one. Apparently it worked without stopping in the previous implementation, but that was not intended as far as I know. A animation is treated like all other actions and cocos doesn't check whether a action of the same type is already running when scheduling a new one.

I may have a similar issue to @skyhawk when using repeatforever, no problems in 1.0.1 however in this release the animation flickers like it is randomly adding a blank frame between frames.

I added a 'stopAllActions' to this sprite before starting the animation and this fixed it however this was not a 'feature' previously?

It looks like after fixing my code I was able to fix the animation. I may have been calling it twice or something. Also I don't have any trim on the sprites, the frames were made with the same height/width.

thanks,

I guess that would be the one... Blackmarq, are you using sprites where each animation frame has a different trim?

I have 3 animations for right, up and down (each direction has 2 frames). The right animation seems to be working, but when the sprite switches direction, I stop the current animation and run another (up or down), on up or down it flickers between the up/down and right animation. I think I see something in the code that I'm going to fix to see if that helps.

What exactly do you mean with flicker? Yesterday I've fixed a bug where differently trimmed ore differently sized animation frames were displayed at the wrong position. It sounds like you could be having the same issue.

Hi,

I've applied the fixes for the ccanimation and ccsprite, however I'm still having issues. I have a sprite/animation moving across a grid and switching animations during turns, however the animation appears to flicker at times. I've tried setting the restoreOriginalFrame (to YES/NO) however it doesn't appear to fix the issue. Any ideas?

Besides the things I've said here, the grabber needs the alpha channel to get the transparency right.

Thanks! that works. Ok, so if I initialise the EAGLView with kEAGLColorFormatRGBA8 instead, what's the difference? Sorry for the ignorance!!

@itlgames, the grabber that is used internally by the grid effects doesn't support transparency when used with a color buffer of RGB565. Several people encountered this, so I added a warning. Since it does work with non transparent parts, I'll change the assert into a log message..

https://github.com/cocos2d/cocos2d-iphone/commit/beb15be6ddcd0fa4ac023fc03c5459efc9d5038b

Hey @araker, I found an issue on latest version, I just updated to your latest developer version since I was having the CCAnimation issue, that works now, but I found that a call to CCRipple3D crashes the game:

*** Assertion failure in -[CCGrabber beforeRender:], /libs/cocos2d/CCGrabber.m:66

The code I had before, was working fine, it's just an action:

CCSprite *splash = [CCSprite spriteWithFile:@"Loading.png"];
[splash setPosition:ccp(size.width/2, size.height/2)];
[splash setOpacity:0];
[self addChild:splash z:2 tag:2];

CCRipple3D *waterEffect = [CCRipple3D actionWithPosition:ccp(size.width/2,size.height/2) radius:140*CC_CONTENT_SCALE_FACTOR() waves:4 amplitude:100 grid:ccg(32*CC_CONTENT_SCALE_FACTOR(),24*CC_CONTENT_SCALE_FACTOR()) duration:2.0f];

id action = [CCSequence actions:
                 [CCFadeIn actionWithDuration:0.2],
                 [CCDelayTime actionWithDuration:1.0],
                 [CCCallFunc actionWithTarget:self selector:@selector(playDrop:)],
				 waterEffect,
                 [CCFadeOut actionWithDuration:0.3],
                 [CCCallFunc actionWithTarget:self selector:@selector(loadHome:)],
                 nil];
[splash runAction:action];

If I comment the waterEffect it doesn't crash.

@araker Ah, so 1.1 is ARC compatible as a cocos2d.a lib but not as raw source -- Good to know, thanks for the info!

@ShyinySteelRobot, 1.1 is ARC compatible, but doesn't support ARC in the cocos2d classes. This is because 1.1 is the compatibility branch, that compiles till 3.0.

To get this to work you'll need to add cocos2d as a external library to use in your ARC project. This tutorial shows how. The part about changing the cocos source is obsolete, those changes are already implemented.

Cocos 2.0. doesn't need to be compatible with older OS versions and uses ARC internally.

Maybe (probably? :) I did something wrong, but when I upgraded to 1.1b2 and then converted my project to ARC, it seemed like ARC had several issues with 1.1b2.

So I upgraded to 2.0 rc0 instead. Interestingly, when I did that and then converted to ARC everything worked fine.

@Mark, thanks it's fixed..

https://github.com/cocos2d/cocos2d-iphone/commit/10b67e7a4c1ea566af6d6bcae0de8bd99f9f4090

@araker,

Thank you for this release. Lots of good stuff in here.

I think there may be an issue with the iOS project architecture settings. I'm using the latest develop commit from 2012-03-18 ( https://github.com/cocos2d/cocos2d-iphone/commit/850ded6733d39e3db03d44f8219504c3723f014b )

Build settings for the iOS project Architectures is set to armv6 armv7 $(ARCHS_STANDARD_32_BIT)

The $(ARCHS_STANDARD_32_BIT) duplicates the armv7 setting, which was giving me issues when building on a device, with errors regarding duplicate symbols.

I'm not sure what would be more appropriate, but I think the Architectures setting should be either:

armv6 armv7
or
armv6 $(ARCHS_STANDARD_32_BIT)

Thanks,

Mark

@itlgames, thanks for mentioning. Fixed it already in the developer branch though..
https://github.com/cocos2d/cocos2d-iphone/commit/850ded6733d39e3db03d44f8219504c3723f014b

@araker just small issue, not big deal, but worth mentioning, there is a warning on CCTMXXMLParser.m file cos a conflict on parseXMLData (interface as "- (NSError*) parseXMLData:(NSData*)data;" and implementation as "- (void) parseXMLData:(NSData*)data"

Just curious, I see that c2d 2.0 requires MacOS X 10.6 if you're building for the Mac platform. Is c2d 1.1 also 10.6 or 10.5 or..? I couldn't find that information for either 1.0.1 or 1.1.

@adamk77, thanks that's a bug indeed, patched.

https://github.com/cocos2d/cocos2d-iphone/commit/778d57d7a899b183391cecc175397d423865054d

@skyhawk, I've applied your patch, thanks.

https://github.com/cocos2d/cocos2d-iphone/commit/d178d46309e7847300d57be3cac022b2d5da1fc7

@clarus, the minimum os version will stay the same.

@Japps, in the next release I'll update the external libraries.

Good job, any plan to include newer version of Box2d?

Thanks guys.

@clarus,

Yes, it's the same, I'm compiling my project with deploy of iOS 3.1 and base SDK of iOS 5.1 and it works fine.

@clarus I have not noticed any changes suggesting that minimum iOS version has changed.

@araker What's the minimum iOS version for cocos2d 1.1? Is it the same as 1.0.1?

I _think_ this may be a bug?

When calling CCAnimation initWithFrames, it seems to convert each CCSpriteFrame into CCAnimationFrame. And when calling setDisplayFrameWithAnimationName: index: it calls setDisplayFrame:, which tries to access the offsetInPixels property. But it throws a unrecognized selector set to isntance exception because CCAniimationFrame doesn't have that property.