Thanks for the help. it is much appreciated.
Interesting, that is what I thought initially. But recently I created an CCAnimation based on a series of CCSpriteFrames and added them to a CCSprite. (Which was in turn added to a CCLayer). (This was pretty much a modified version of the code I saw in SpriteTest.) I started the animation using a runAction (forever).
I then added more animations to the sprite and created some more actions. Then based upon user input, I did a stopAllActions and started a new action.
Initially the results were fine. I had changing animations based upon input, etc. However, once I started changing the initial animations things started getting weird. I had all sorts of corrupted *looking* sprites and sometimes no visual sprite at all. Certain combinations of animations would work and others would not. My first thought was that I loaded the CCAnimatons incorrectly, but I tested (and displayed) them all and they looked fine. The issue would happen with as little as two different animations (the initial and one added).
I dropped the code complexity down a bit and instead of doing actions,I just created an additional CCAnimation and added it to the same Sprite. (No actions, just used the 0th frame for the sprite initially). Later, based on input,etc, I changed the Sprite's look by simply using [sprite setDisplayFrame:<2ndAnimationName> index:0]; (Note that I was ONLY using the 0th index of any animation just to make it as simple as possible).
Again I had the same result.
I did alot of searching on the forums,etc. Eventually I ran across a post (by req, as I recall) about a hack for changing the Texture2D in a sprite (after creation).
So what I did was to basically change the Texture2d right before I called SetDisplayFrame the sprite was using. Soon as I did that it worked perfectly! This experience was what prompted me to start thinking that perhaps limitation of a single Texture2D for a sprite applied to all CCSprites, not just those parented by CCSpriteSheet.
I realize that I haven't posted any code (as I really would need to distill it down to a simple example, and at this point I am thinking I might as well just start using CCSpritesheets), and it certainly could be some issue in my code (okay, probably ;-). What is strange though is that was that changing the Texture2d reference would fix the issue so completely. (I mean I tried to break it again using all sorts of animation combinations, and it seems very stable now).
If I take out [sprite setTexture:texture]; I get weirdly displayed sprites. Add the line back in an *bam* works fine.
I dug into the CCSprite code a bit and I located something that confuses me a little.
SetDisplayFrame looks like this:
-(void) setDisplayFrame:(id)newFrame
{
CCSpriteFrame *frame = (CCSpriteFrame*)newFrame;
// update anchor point
anchorPoint_ = ccp( (- frame.offset.x / frame.rect.size.width) + 0.5f,
( - frame.offset.y / frame.rect.size.height) + 0.5f );
// update rect
CGRect rect = [frame rect];
[self setTextureRect: rect];
[self setFlipX: [frame flipX]];
[self setFlipY: [frame flipY]];
// update texture
if ( frame.texture.name != self.texture.name )
[self setTexture: frame.texture];
}
as you can see, the method above eventually calls setTexture (which update selfRenderTextureAtlas_ as well) ...however it is doing so at the end of the method.
What confuses me is that before the SetTexture is called inside setDisplayFrame, this call is being made:
[self setTextureRect: rect];
which in turn (internally) makes the call:
[selfRenderTextureAtlas_ updateQuad:&quad_ atIndex:0];
so I was curious if setTexture should be called before setTextureRect so that selfRenderTextureAtlas_ is referencing the new frame's texture as opposed to the sprite's old texture?
As I said in my OP, I am pretty new to cocos2d, so I don't mean to assume I understand all the inner workings, but like I said, I was curious about this as it seems to be at the heart of the issue I am experiencing.
