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)-
Posted 2 years ago #
-
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 # -
I would suggest to use three values for flipX in frames:
-UseSpriteValue(default)
-false
-trueOnly when the value of a frame is set to true or false it will use this setting otherwise it will use the flipX value of the sprite.
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 # -
Sorry if I'm' not caught up on the releases but was this in the 0.9-beta2 release? I kind of depend on the CCSprite.flipX to mirror the same sprite as well as it's animations.
Posted 2 years ago # -
v0.9-beta2 contains flips in sprite. Please, see
tests/SpritesTest.mto see how to use it.Posted 2 years ago # -
Riq, so I will have to use the CCFlipX instead in beta2?
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 # -
@riq: Maybe I'm missing something here but I tried to use the sprite.flipX and it does not flip my image at all. I'm trying to do this without using the CCFlipX action if possible and I am currently using the beta2 release.
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 # -
Perhaps 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 # -
Okay, 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 # -
riq, I know you're busy on the upcoming release but does the above make sense to you? I would love to migrate but would like to know if it's an issue for either versions.
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 # -
@riq, I will give it a try as soon as I can move back. I should grab the trunk right?
Posted 2 years ago # -
@seveace6: yes. you should grab trunk.
Posted 2 years ago #
Reply
You must log in to post.