The annoying part with this is when applying actions, you have to track the state to remember whether or not to apply the action to the AtlasSprite from sheet1 or sheet 2. In my game, this wasn’t an issue since I didn’t use actions that much, but for other games this could be a major hassle.

You are correct, you could just create many copies of the SpriteManagers and the texture manager would only load the sprite sheet once. However, you can’t just make one AtlasSpriteManager per AtlasSprite as that just as slow as Sprite, so you still need to share the managers to some extent. And each time you create another Manager for the same texture, you are throwing away the entire performance gain that you get from using a single Manager for one texture.

Read on the cocos2d forums about why AtlasSpriteManager is there. It will not be dropped, because it is a useful tool that you can use to ‘batch’ opengl calls without having to delve into the OpenGL yourself. By twisting your code around to fit this seemingly arbitrary design structure, you vastly increase the efficiency of the OpenGL code running underneath it by allowing OpenGL to copy many different parts of the same texture in one big operation, avoiding the overhead of many small operations.

Thanks, and good luck on your project!

I suppose even if you have several sprite managers using the same texture, cocos2d keeps a single texture on the openGLES memory – but someone more smart than me could really confirm it commenting after.

In the end, I guess the AtlasSpriteManager could be ‘dropped’ from cocos2d… and its functionality could be put inside AtlasSprite directly – and atlasSprites would be using a Texture2d or something directly. I think it would make things easier and more flexible (mainly about Z).

By the way, congrats for StickWars! Wish you all the success!

Some of this implementation is particular to my own game, though it may be helpful for other games.

Question: are you creating an “inside particular” sprite manager for each “sprite” you raise? Is this because of the difficulty of controlling the z?

I am using a single (shared) sprite manager as a “Static” variable in my “enemy” class, used by all sprite instances.

spriteManager1 = [[AtlasSpriteManager alloc] initWithFile:@”smallstick_common.png” capacity:50];

All those are doing is setting up the texture tool to use aliased textures (versus anti-aliased). Capacity refers to the number of AtlasSprites frames you plan to add as a child to that AtlasSpriteManager. If you are creating 50 frames (say 5 animations with 10 frames each) then you give it a capacity of 50. However, you do not have to be exact with this, you could leave it at 1 and it would just take a little more time at run-time to resize the array.

there are a couple of snippets that I did not understand:

[Texture2D saveTexParameters];
[Texture2D setAliasTexParameters];
spriteManager1 = [[AtlasSpriteManager alloc] initWithFile:@”smallstick_common.png” capacity:50];
[Texture2D restoreTexParameters];

what exactly is being done here? What are all those calls made to Texture2D? I tried looking at Texture2D.h but with basically no OpenGL background I couldn’t understand.

Also, what does “capacity” mean for a textureAtlas anyway?

However, I knew beforehand that no single Sprite would need to access more than 2 spritesheets, so this way took a little less time to throw together. It’s not extensible coding, but sometimes you have to make sacrifices when pumping out updates every 1.5 weeks!

But the question is, since a single spritesheet can be up to 1024×1024, would you really need a sprite that needs to draw from more than 2-3 of them? Maybe you do, but I didn’t for my game. Sorry I didn’t come up with a more generic solution, but I’m still relatively new to ObjC and Cocos2d.