I have just migrated to the v0.9 beta and I'm having some issues with the behaviour of CCSprite.flipX. In v0.8.2 if you set flipX to true on an AtlasSprite any AtlasAnimation that you run on that sprite would be flipped. This doesn't seem to be happening for me in the v0.9. When I set flipX to true on my CCSprite it flips but as soon as I run an animation on the sprite the animation frames aren't flipped. I can manually flip each animation frame and set up a second animation but I was wondering if this is really necessary, perhaps I'm just doing something wrong?
Animation with flipX in v0.9
(18 posts) (5 voices)-
yes, it is a feature (or a bug)
in v0.9-beta Animation overrides the "flip" value of the frame, and this is because theSpriteFramesupports the flip property.tests/SpriteTest.mcomes with an example (see the dragon example) that flips the image using animation.My question is:
- ShouldSpriteFramesupport theflipproperty ? (if so, then animation will override the flip value), or not ?My intuition tells me that
SpriteFrameshould support theflipproperty, but I'm not 100% sure about it.Pros and cons of supporting
flipinSpriteFrame:
+ less code regarding the logic. You just play another animation.
+ These "flipped" animations don't use additional texture memory. The only use a few additional bytes of memory
- There is no visual editor that let's you create these animations. You have to edit the .plist file manually[Update]:
PerhapsAnimationshould have a new method that let you create a flipped animation.
eg:CCAnimation *forward = [CCAnimation animationWtih....]; CCAnimation *backward = [forward newflippedAnimationOnX:YES y:NO];Ideas ?
Posted 2 years ago # -
@nightmare: yes, that's a good idea.
For the moment I'll rollback theCCSpriteFrame flipfeature, and it won't override theflipproperty. So you will be able to flip and sprite and the animation won't modify it's properties.I've also added 2 new actions:
CCFlipXandCCFlipY.
SVN r1623Posted 2 years ago # -
v0.9-beta2 contains flips in sprite. Please, see
tests/SpritesTest.mto see how to use it.Posted 2 years ago # -
You can use the action
CCFlipXor you can use the propertyflipX.eg:
sprite.flipX = YES; sprite.flipY = YES;Posted 2 years ago # -
stange. Please, see the
tests/SpriteTest.m(included in cocos2d) to see how to use it. Perhaps you are doing something different from the test case.Posted 2 years ago # -
serveace6
MemberPerhaps I'm using zwoptex tool to create the sprite? Here's a sample of what I'm doing,
sprite = [CCSprite spriteWithSpriteFrameName:@"facerightarrow.png"]; CCSpriteSheet *spriteSheet = [CCSpriteSheet spriteSheetWithFile:@"sprites.png"]; [spriteSheet addChild:sprite]; [self addChild:spriteSheet]; sprite.flipX = YES;As this is rendered, the image of the arrow is not flipped.
Posted 2 years ago # -
your code seems to be OK. Could you try with the latest SVN version ?
And if it doesn't work, could you open a bug on the issue tracker ? thanks.Posted 2 years ago # -
serveace6
MemberOkay, I spent more time on debugging the issue and I was able to isolate and confirm that the CCSprite.flipX works as expected in beta2. However, the thing that lead me to believe it was an issue revealed another possible issue. Below is what I did to trigger the new issue:
sprite = [CCSprite spriteWithSpriteFrameName:@"facerightarrow.png"]; CCSpriteSheet *spriteSheet = [CCSpriteSheet spriteSheetWithFile:@"sprites.png"]; [spriteSheet addChild:sprite]; [self addChild:spriteSheet]; sprite.flipX = YES; sprite.scale = 1.0;The only new addition to the original code snippet is that I set scale immediately after I set the flipX value. What happens afterward is that the flipX value appears revert back to the the original value and therefore lead me to believe that the CCSprite.flipX is not working in the first place. This was not an issue in 0.8.2 and now I'm wondering if it's intended behavior or just a bug in the new version.
Posted 2 years ago # -
-
While folks are looking into potential issues with flipX I figured I'd throw this one in that I saw in a pull from SVN last night:
Setting flipX on the sprite itself calls setTextureRect directly w/out an untrimmed size ...
if( flipX_ != b ) {
flipX_ = b;
[self setTextureRect:rect_];
}This will cause the contentSize to revert to the trimmed size if the sprite originated from Zwoptex
Replacing the direct call to setTextureRect with only the needed parts i.e.
[self updateTextureCoords:rect_];
// rendering using SpriteSheet
if( usesSpriteSheet_ ) {
dirty_ = YES;
}// self rendering
else
{
// Atlas: Vertex
float x1 = 0 + offsetPosition_.x;
float y1 = 0 + offsetPosition_.y;
float x2 = x1 + rect_.size.width;
float y2 = y1 + rect_.size.height;// Don't update Z.
quad_.bl.vertices = (ccVertex3F) { x1, y1, 0 };
quad_.br.vertices = (ccVertex3F) { x2, y1, 0 };
quad_.tl.vertices = (ccVertex3F) { x1, y2, 0 };
quad_.tr.vertices = (ccVertex3F) { x2, y2, 0 };
}seems to take care of the issue but I doubt that's really the fix we'd want to apply :)
Posted 2 years ago # -
@seveace6: yes. you should grab trunk.
Posted 2 years ago #
Reply
You must log in to post.