In this chapter, I focus on working with sprites. You can create sprites in numerous ways from individual image files and texture atlases. I also explain how to create and play sprite animations.

A texture atlas is a regular texture that contains more than one image. Often it’s used to store all animation frames of a single character in one texture, but it’s not limited to that—in fact, you can place any image into a texture atlas. The goal is to get as many images as possible into each texture atlas. To help create a texture atlas, you have a great tool to rely on called TexturePacker, also introduced in this chapter.

Sprite batching is a technique for speeding up the drawing of sprites. As the name implies, batching sprites allows the GPU to render all the sprites in one go (or in technical terms, in one draw call). It speeds up drawing identical sprites but is most effective when using a texture atlas. If you use a texture atlas along with sprite batching, you can draw all the images in that texture atlas in one draw call.

A draw call is the process of transmitting the necessary information to the graphics hardware in order to render a texture or parts of it. For example, when you’re using the spriteFromFile method to create a CCSprite node, that sprite creates one draw call. The CPU overhead for issuing each draw call can add up so much that it can decrease the framerate, particularly when you want to display more sprites.

CCSpriteBatchNode functions like an extra layer to which you can add sprite nodes, as long as they all use the same texture. From then on, all the sprite children of the CCSpriteBatchNode are drawn with a single draw call. Effectively, the CPU tells the GPU what texture it should draw from but also passes a long list of frames and positions to the GPU so it can render a large number of sprites from that texture all by itself.

To summarize: sprite batching speeds up drawing identical sprites using the same texture and is most effective when using a texture atlas created with TexturePacker. The more sprites you display onscreen, and the bigger the sprites are (and particularly if they’re rotated and scaled too), the greater the benefit of using sprite batching.

The lessons you’ll learn in this chapter will become the foundation for the parallax-scrolling shoot-’em-up game in Chapters 7 and 8.

Retina Display

The newer iPhone models starting with iPhone 4 use a high-resolution display called the Retina display. It has a resolution of 960×640 pixels, which doubles the number of pixels in each direction (previous-generation devices were 480×320 pixels). The 3rd-generation iPad also has a Retina display, doubling the resolution of previous iPads from 1024×768 pixels to 2048×1536 pixels.

To make this distinction, the Retina display graphics are commonly called high-definition (HD) graphics, whereas non-Retina graphics are standard-definition (SD) graphics. HD is not limited to image files. Cocos2d also supports HD resolution versions of particle effects, bitmap fonts, and tilemaps. For each of those, you should create the HD version first and then downscale the asset for SD resolution.

Table 6-1 sketches a brief overview of the technical specifications of iOS devices. If you recall from Chapter 2, cocos2d 2.0 doesn’t support 1st- and 2nd-generation devices, but they’re in the table for comparison. One thing to keep in mind: the maximum texture size for iPad 2 has been increased to 4096×4096 but only if the device is running iOS 5.1 or newer.

Cocos2d uses a resolution-independent coordinate system using points instead of pixels. One point is exactly one pixel on the SD devices, but one point is two pixels on Retina display devices. By writing all positions in points, the coordinates will remain the same on both devices! On a Retina iPhone the pixel resolution is 960×640, but the point resolution remains 480×320, which makes it a lot easier to develop apps for both Retina and non-Retina devices.

Cocos2d is smart when it comes to loading images. If your code has Retina support enabled, and the app is running on an iPhone or iPod touch device that has a Retina display, cocos2d tries to load a sprite with the -hd suffix first. When the app is running on a Retina iPad, cocos2d looks for the sprite with the –ipadhd suffix instead. These suffixes are not fixed and can be changed through the CCFileUtils singleton class, although I recommended sticking with the defaults as they’re most widely supported by third-party tools. You can find this code with explanations in newly created cocos2d projects in the AppDelegate.m file:

// If the 1st suffix is not found and if fallback is enabled then fallback suffixes
// are searched. If no fallback file is found, it will try the file without any suffix.
// On iPad Retina : "-ipadhd", fallback: "-ipad", second fallback: "-hd"
// On iPad : "-ipad", fallback: "-hd"
// On iPhone Retina: "-hd"
 
CCFileUtils *sharedFileUtils = [CCFileUtils sharedFileUtils];
[sharedFileUtils setEnableFallbackSuffixes:NO];
[sharedFileUtils setiPhoneRetinaDisplaySuffix:@"-hd"];
[sharedFileUtils setiPadSuffix:@"-ipad"];
[sharedFileUtils setiPadRetinaDisplaySuffix:@"-ipadhd"];

So if you specify in your code to load a file named ship.png, then on a Retina display device it will first try to load ship-hd.png, and if that file doesn’t exist or the device isn’t a Retina display device, the SD image ship.png is loaded. On the iPad it tries to load the ship-ipad.png file and, if fallback is enabled, it also tries loading ship-hd.png before trying to load ship.png. On the Retina iPad cocos2d first looks for ship-ipadhd.png and, if fallback is enabled, it also tries ship-ipad.png, followed by ship-hd.png, before finally reverting to load ship.png.

Because those fallback mechanisms can be quite tricky to get right, I strongly recommend that you provide assets for all variants. For iPhone and iPod touch apps, you need standard resolution files with no suffix and the Retina resolution with the –hd suffix. For iPad apps, you will want to supply -ipad and -ipadhd assets. And for a universal app, you should really provide all four variants.

Of course, this makes sense only if all HD images have exactly twice the resolution of the SD ones. Otherwise, you’ll notice that HD images which are not exactly twice the resolution are more or less offset when displayed in your app. In general, you should avoid using HD images, whose pixel resolution is not divisible by two without a remainder. If you do support Retina displays, you should create all images in HD resolution first and then scale them down by 50 percent and save them as the SD images. Upscaling SD images doesn’t give you Retina display quality with more image details—that can only be done by the computer experts on CSI. The programming community at large is still perplexed about how they do that.

The nice thing about cocos2d’s HD image support is that your game doesn’t even have to know if it’s running on a Retina device. The code is the same. The only thing you do need to care about is that you need two images instead of one, or four if you create a universal app.

In theory, it’s also possible to use only HD graphics and then scale them down at runtime using the scale property of sprites to match the display resolution. But this comes with a major drawback: memory usage! The HD image in Figure 6-1 uses 128 KB of texture memory, assuming 32-bit color quality. The SD version consumes only 32 KB of memory. The non-Retina devices have generally half the memory (or less) than Retina devices and quickly run out of memory when you have them load textures taking up four times as much memory as needed.

Displaying a scaled-down version of an image also incurs a performance penalty because four times more pixels must be processed each frame to display a scaled-down version of the image. On the other hand, upscaling standard resolution images for Retina devices simply provides no visual improvement, so you could just as well disable Retina mode in cocos2d altogether and simply provide only SD assets.

To enable support for Retina display resolutions in cocos2d, you must call the CCDirector method enableRetinaDisplay. Typically this is already done as part of the AppDelegate initialization code, so you only need to change this if you absolutely don’t plan to have Retina assets in your app and want to disable Retina mode.

if (![director enableRetinaDisplay:YES])
{
  CCLOG(@"Retina Display Not supported");
}

CCSpriteBatchNode

Every time a texture is drawn on the screen, the graphics hardware has to prepare the rendering, render the graphics, and clean up after rendering. There’s an inherent overhead caused by starting and ending the rendering of a single texture. You can alleviate it by letting the graphics hardware know that you have a group of sprites that should be rendered using the same texture. In that case, the graphics hardware will perform the preparation and cleanup steps only once for a group of sprites.

Figure 6-2 shows an example of this kind of batch rendering. You can see the hundreds of identical bullets on the screen. If you rendered them each one at a time, your framerate would drop by at least 15 percent in this case, and by a lot more if the bullet texture were larger and the sprites were rotated and scaled. With a CCSpriteBatchNode, you can keep your app running at top speed. To test the effect of sprite batching, try out the Kobold2D template project named Sprite-Performance and read my blog post about sprite batch performance here: www.learn-cocos2d.com/2011/09/cocos2d-spritebatch-performance-test.

As a refresher, here’s how to create a CCSprite the normal way:

CCSprite* sprite = [CCSprite spriteWithFile:@"bullet.png"];
[self addChild:sprite];

Listing 6-1 changes the creation of the same CCSprite to use a CCSpriteBatchNode instead. Of course, just adding one CCSprite to it won’t give you any benefit, so I’ll be adding a number of sprites using the same texture to the CCSpriteBatchNode.

Listing 6-1.  Creating Multiple CCSprites and Adding Them to a CCSpriteBatchNode to Render Them Faster

CCSpriteBatchNode* batch = [CCSpriteBatchNode batchNodeWithFile:@"bullet.png"];
[self addChild:batch];
 
for (int i = 0; i < 100; i++)
{
  CCSprite* bullet = [CCSprite spriteWithFile:@"bullet.png"];
  [batch addChild:bullet];
}

Notice that in Listing 6-1 the CCSpriteBatchNode takes a file as an argument, even though the CCSpriteBatchNode itself isn’t displayed. It’s more like a CCLayer in that regard, except that you can add only CCSprite nodes to it. The reason it takes an image file as an argument is that all CCSprite nodes added to the CCSpriteBatchNode must use the same texture. If you accidentally add a sprite with a different texture, or a non-sprite node to the batch node, you’ll see one of these two error messages in the Debug Console:

'NSInternalInconsistencyException', reason: 'CCSprite is not using the same texture id'
'NSInternalInconsistencyException', reason: 'CCSpriteBatchNode only supports CCSprites as children'

-(id) init
{
  if ((self = [super initWithFile:@"ship.png"]))
  {
      [self scheduleUpdate];
  }
  return self;
}

-(id) initWithShipImage
{
  if ((self = [super initWithFile:@"ship.png"]))
  {
      [self scheduleUpdate];
  }
  return self;
}

-(void) update:(ccTime)delta
{
  // Keep creating new bullets
  Bullet* bullet = [Bullet bulletWithShip:self];
 
  // Add the bullets to the ship's parent
  CCNode* gameScene = [self parent];
  [gameScene addChild:bullet z:0 tag:GameSceneNodeTagBullet];
}

-(void) update:(ccTime)delta
{
  // update position of the bullet
  // multiply the velocity by the time since the last update was called
  // this ensures same bullet velocity even if framerate drops
  self.position = ccpAdd(self.position, ccpMult(velocity, delta));
 
  // delete the bullet if it leaves the screen
  if (self.position.x > outsideScreen)
  {
      [self removeFromParentAndCleanup:YES];
  }
}

static GameScene* sharedGameLayer;
+(GameScene*) sharedGameLayer
{
    NSAssert(sharedGameLayer ! = nil, @" instance not yet initialized!");
    return sharedGameLayer;
}
-(id) init
{
 if ((self = [super init]))
  {
     sharedGameLayer = self;
     . . .
     CCSpriteBatchNode* batch = [CCSpriteBatchNode batchNodeWithFile:@"bullet.png"];
     [self addChild:batch z:1 tag:GameSceneNodeTagBulletSpriteBatch];
  }
  return self;
}
 
-(void) dealloc
{
    sharedGameLayer = nil;
}
 
-(CCSpriteBatchNode*) bulletSpriteBatch
{
    CCNode* node = [self getChildByTag:GameSceneNodeTagBulletSpriteBatch];
    NSAssert([node isKindOfClass:[CCSpriteBatchNode class]], @"not a SpriteBatch");
    return (CCSpriteBatchNode*)node;
}

-(void) update:(ccTime)delta
{
  Bullet* bullet = [Bullet bulletWithShip:self];
  [[[GameLayer sharedGameLayer] bulletSpriteBatch] addChild:bullet
                                                          z:0
                                                        tag:GameSceneNodeTagBullet];
}

CCSpriteBatchNode* batch = [CCSpriteBatchNode batchNodeWithFile:@"bullet.png"];
[self addChild:batch z:0 tag:GameSceneNodeTagBulletSpriteBatch];
 
// Create a number of bullets up front and reuse them whenever necessary.
for (int i = 0; i < 400; i++)
{
    Bullet* bullet = [Bullet bullet];
    bullet.visible = NO;
    [batch addChild:bullet];
}

-(void) shootBulletFromShip:(Ship*)ship
{
    CCArray* bullets = [self.bulletSpriteBatch children];

    CCNode* node = [bullets objectAtIndex:nextInactiveBullet];
    NSAssert([node isKindOfClass:[Bullet class]], @"not a bullet!");
 
    Bullet* bullet = (Bullet*)node;
    [bullet shootBulletFromShip:ship];
 
    nextInactiveBullet++;
    if (nextInactiveBullet >= bullets.count)
    {
        nextInactiveBullet = 0;
    }
}

-(void) shootBulletFromShip:(Ship*)ship
{
  float spread = (CCRANDOM_0_1() - 0.5f) * 0.5f;
  velocity = CGPointMake(1, spread);
 
  outsideScreen = [CCDirector sharedDirector].winSize.width;
  self.position = CGPointMake(ship.position.x + ship.contentSize.width * 0.5f, ←
       ship.position.y;
  self.visible = YES;
 
  [self scheduleUpdate];
}
-(void) update:(ccTime)delta
{
  self.position = ccpAdd(self.position, velocity);
  if (self.position.x > outsideScreen)
  {
       self.visible = NO;
       [self unscheduleUpdate];
  }
}

Sprite Animations the Hard Way

Now brace yourself. I’d like to show you how sprite animations work. Figure 6-3 shows the ship’s animation frames. Remember that you have the entire animation in both HD and SD resolution.

Sprite animations are another good reason to use CCSpriteBatchNode, because you can put all animation frames into the same texture to conserve memory. It’s quite a bit of code actually, as you’ll see in Listing 6-11 and in the Sprites01 project. After that, I show you how to create the same animation using a texture atlas, which cuts down the amount of code you have to write.

Listing 6-11.  Adding an Animation to the Ship Without Using a Texture Atlas Requires Quite a Bit of Code

// Load the ship's animation frames as textures and create a sprite frame
NSMutableArray* frames = [NSMutableArray arrayWithCapacity:5];
for (int i = 0; i < 5; i++)
{
    // Create a texture for the animation frame
    NSString* file = [NSString stringWithFormat:@"ship-anim%i.png", i];
    CCTexture2D* texture = [[CCTextureCache sharedTextureCache] addImage:file];
 
    // The whole image should be used as the animation frame
    CGSize texSize = texture.contentSize;
    CGRect texRect = CGRectMake(0, 0, texSize.width, texSize.height);
 
    // Create a sprite frame from the texture
    CCSpriteFrame* frame = [CCSpriteFrame frameWithTexture:texture rect:texRect];
    [frames addObject:frame];
}
// Create an animation object from all the sprite animation frames
CCAnimation* anim = [CCAnimation animationWithSpriteFrames:frames delay:0.08f];

// Run the animation by using the CCAnimate action and loop it with CCRepeatForever
CCAnimate* animate = [CCAnimate actionWithAnimation:anim];
CCRepeatForever* repeat = [CCRepeatForever actionWithAction:animate];
[self runAction:repeat];

All that just to create a sprite animation with five frames? I’m afraid so. I’ll walk you through the code backward this time, which may explain the setup better. At the very end you’re using a CCAnimate action to play an animation. In this case, you’re also using a CCRepeatForever action to loop the animation.

The CCAnimate action uses a CCAnimation object (which is a container for animation frames) that defines the delay between each individual frame. In many cases, you’ll later want to refer to a previously created animation. For that purpose, cocos2d has a CCAnimationCache class that stores CCAnimation instances by name, as shown in Listing 6-12. Using the CCAnimationCache, you can access a particular animation by name later.

Listing 6-12.  The CCAnimationCache Class Can Store Animations for You, Which Can Be Retrieved by Name

CCAnimation* anim = [CCAnimation animationWithSpriteFrames:frames delay:1];
 
// Store the animation in the CCAnimationCache
[[CCAnimationCache sharedAnimationCache] addAnimation:anim name:@"move"];

// Sometime later: retrieve the move animation from the CCAnimationCache
CCAnimation* move = [[CCAnimationCache sharedAnimationCache] animationByName:@"move"];

Going back to Listing 6-11, notice the for loop. This is where it gets complicated. The CCAnimation class must be initialized with an NSArray containing CCSpriteFrame objects. A sprite frame consists only of a reference to a texture and a rectangle that defines the area of the texture that should be drawn. The texture rectangle equals the texture’s contentSize property—in other words, the size of the actual image contained in the texture. Keep in mind that the texture can be bigger than the image it contains because textures can only have dimensions that are powers of two.

Now, unfortunately the CCSpriteFrame doesn’t take an image filename as input; it only accepts existing CCTexture2D objects. You create the texture using the CCTextureCache singleton’s addImage method, normally used to preload images as textures into memory without having to create a CCSprite or other object. You construct the filename using NSString’s stringWithFormat method, which allows you to use the loop variable i to be appended to the filename, instead of having to write out all five filenames.

To recap, from top to bottom, here’s how you can create and run a sprite animation:

1. Create NSMutableArray.
2. For each animation frame:

   a.  Create a CCTexture2D for each image.

   b.  Create a CCSpriteFrame using the CCTexture2D.

   c.  Add each CCSpriteFrame to the NSMutableArray.

3. Create a CCAnimation using the frames in the NSMutableArray.
4. Optionally, add the CCAnimation to the CCAnimationCache with a name.
5. Use a CCAnimate action to play the animation.

Shh, calm down—no need to take that Valium. If you pack your animation frames into a texture atlas, things will get a bit easier and more efficient at the same time. More helpful is to encapsulate all this code into a helper method and stick to a naming convention for your animation files.

Animation Helper Category

Because the code to create the animation frames and the animation is common to all animations, you should consider encapsulating this into a helper method. I’ve done so by adding the CCAnimationHelper class to the project Sprite01. Instead of using static methods, I extend the CCAnimation class using an Objective-C feature called a category. Categories offer a way to add methods to an existing class without having to modify the original class. The only downside is that with a category you can’t add member variables to the class; you can only add methods. The following code is the @interface for the CCAnimation category, which I informally named Helper:

@interface CCAnimation (Helper)
+(CCAnimation*) animationWithFile:(NSString*)name
                       frameCount:(int)frameCount
                            delay:(float)delay;
@end

The @interface for an Objective-C category uses the same name as the class it extends and adds a category name within parentheses. The category name is like a variable name and thus cannot contain spaces or other characters you can’t use in variables—punctuation characters, for example. The @interface also must not contain curly brackets, because adding member variables to a category isn’t possible or allowed.

The actual @implementation for the CCAnimation category uses the same schema as the @interface by appending the category name in parentheses after the class name. Everything else is just like writing regular class methods; in this case, my extension method is named animationWithFile and takes the filename, the number of frames, and the animation delay as input:

@implementation CCAnimation (Helper)

// Creates an animation from single files
+(CCAnimation*) animationWithFile:(NSString*)name
                       frameCount:(int)frameCount
                            delay:(float)delay
{
  // Load the animation frames as textures and create the sprite frames
  NSMutableArray* frames = [NSMutableArray arrayWithCapacity:frameCount];
  for (int i = 0; i < frameCount; i++)
  {
      // Assuming all animation files are named "nameX.png"
      NSString* file = [NSString stringWithFormat:@"%@%i.png", name, i];
      CCTexture2D* texture = [[CCTextureCache sharedTextureCache] addImage:file];

      // Assuming that image file animations always use the whole image
      CGSize texSize = texture.contentSize;
      CGRect texRect = CGRectMake(0, 0, texSize.width, texSize.height);
      CCSpriteFrame* frame = [CCSpriteFrame frameWithTexture:texture rect:texRect];
      [frames addObject:frame];
  }
  // Return a CCAnimation object using all the sprite animation frames
  return [CCAnimation animationWithSpriteFrames:frames delay:delay];
}
 
@end

Here’s how the naming convention comes into play. The Ship’s animations have the base name ship-anim followed by a consecutive number starting with 0 and ending in the .png file extension. For example, the filenames for the Ship’s animation are named ship-anim0.png through ship-anim4.png. If you create all your animations using that naming scheme, you can use the preceding CCAnimation extension method for all your animations.

This greatly simplifies the code used to create an animation from individual files:

// The whole shebang is now encapsulated into a Category extension method
CCAnimation* anim = [CCAnimation animationWithFile:@"ship-anim"
                    frameCount:5
                    delay:0.08f];

Essentially this cuts down the number of lines from nine to just this one. As for the filename, you only need to pass the base name of your animation—in this case ship-anim. The helper method adds the consecutive numbers based on the frameCount parameter and also appends the .png file extension. You can also use the base name for the animation as the name for the animation when you add it to the CCAnimationCache so you don’t have to remember alternate names for the same animation. Previously I named the ship’s animation move. Now it’s called ship-anim, in line with the filenames. You could store and access the animation from the CCAnimationCache by using its base name like so:

NSString* shipAnimName = @"ship-anim";
 
CCAnimation* anim = [CCAnimation animationWithFile:shipAnimName
                     frameCount:5
                     delay:0.08f];
[[CCAnimationCache sharedAnimationCache] addAnimation:anim name:shipAnimName];

// sometime later:
CCAnimation* shipAnim = [shipSprite animationByName:shipAnimName];

The animationWithFile helper method makes two assumptions: animation image filenames are consecutively numbered beginning with 0, and the files must have the .png file extension. It’s up to you whether to stick to this exact naming convention or change it to accommodate your own needs. For example, you might find it more convenient to start numbering your animations starting with 1 instead of 0. In that case, you’ll have to change the for loop so that the name string is formatted with i + 1. The important part is to stick to whatever naming convention you choose to make your life (and your code) easier.

You should take away three things from this:

• Encapsulate commonly used code by defining your own methods.
• Use Objective-C categories to add methods to existing classes.
• Define resource filenaming conventions to support your code.

Working with Texture Atlases

Texture atlases help conserve precious memory and speed up the rendering of sprites. Because a texture atlas is nothing but a big texture, you can render all the images it contains using a CCSpriteBatchNode, thus reducing the draw call overhead. Using texture atlases is a win-win for both memory usage and performance.

// Enable pre multiplied alpha for PVR textures to avoid artifacts
[CCTexture2D PVRImagesHavePremultipliedAlpha:YES];

// Load the texture atlas sprite frames; this also loads the Texture with the same name
CCSpriteFrameCache* frameCache = [CCSpriteFrameCache sharedSpriteFrameCache];
[frameCache addSpriteFramesWithFile:@"game-art.plist"];

// Loading the ship's sprite using a sprite frame name (e.g., the file name)
if ((self = [super initWithSpriteFrameName:@"ship.png"]))
{
   // Load the ship's animation frames
   NSMutableArray* frames = [NSMutableArray arrayWithCapacity:5];
   for (int i = 0; i < 5; i++)
   {
        NSString* file = [NSString stringWithFormat:@"ship-anim%i.png", i];

        CCSpriteFrame* frame = [frameCache spriteFrameByName:file];
        [frames addObject:frame];
   }

   // Create an animation object from all the sprite animation frames
   CCAnimation* anim = [CCAnimation animationWithSpriteFrames:frames delay:0.08f];

   // Run the animation by using the CCAnimate action
   CCAnimate* animate = [CCAnimate actionWithAnimation:anim];
   CCRepeatForever* repeat = [CCRepeatForever actionWithAction:animate];
   [self runAction:repeat];
}

CCSprite* sprite = [CCSprite spriteWithSpriteFrameName:@"ship.png"];

interface CCAnimation (Helper)
+(CCAnimation*) animationWithFile:(NSString*)name
                        frameCount:(int)frameCount
                             delay:(float)delay;

+(CCAnimation*) animationWithFrame:(NSString*)frame
                        frameCount:(int)frameCount
                             delay:(float)delay;
@end

// Creates an animation from sprite frames
+(CCAnimation*) animationWithFrame:(NSString*)frame
                        frameCount:(int)frameCount
                             delay:(float)delay
{
  // load the ship's animation frames as textures and create a sprite frame
  NSMutableArray* frames = [NSMutableArray arrayWithCapacity:frameCount];
  for (int i = 0; i < frameCount; i++)
  {
      NSString* file = [NSString stringWithFormat:@"%@%i.png", frame, i];
      CCSpriteFrameCache* frameCache = [CCSpriteFrameCache sharedSpriteFrameCache];
      CCSpriteFrame* frame = [frameCache spriteFrameByName:file];
      [frames addObject:frame];
  }
 
  // Return an animation object from all the sprite animation frames
  return [CCAnimation animationWithSpriteFrames:frames delay:delay];
}

// Create an animation object from all the sprite animation frames
CCAnimation* anim = [CCAnimation animationWithFrame:@"ship-anim"
                    frameCount:5
                    delay:0.08f];

[[CCSpriteFrameCache sharedSpriteFrameCache] removeUnusedSpriteFrames];
[[CCTextureCache sharedTextureCache] removeUnusedTextures];

[CCSpriteFrameCache purgeSharedSpriteFrameCache];
[CCTextureCache purgeSharedTextureCache];

Summary

In this chapter, you learned how to use a CCSpriteBatchNode to render multiple sprites using the same texture faster, whether that texture is a single image or a sprite frame of a texture atlas.

Subclassing your game objects from CCSprite also introduces a few subtle differences and stumbling blocks, which I demonstrated earlier in this chapter, before moving on to show you how to create sprite animations. Because the code to create animations is very complex, I gave you the solution in the form of a CCAnimationHelper category.

I also showed you how to work with texture atlases and why and how you should use them. Of course, one can’t say “texture atlas” without mentioning TexturePacker in the same sentence. It’s hands down the best tool to create and modify texture atlases, and if you don’t want to spend money on it, you can still use the free command-line version without the advanced features.

In the next chapter, you’ll be working on your next game, as we work on making the shooter game playable.