I would like to start this post by introducing some new software that will make the lives of developers much easier. When I first starting developing my new game Elementals HD for the iPhone I had no idea that loading individual PNG’s as textures for sprites would result in a final memory consumption of over 130MB on load. That’s really bad considering that the newest iPod Touch only comes with 256MB of RAM which to this day I will never understand. Apple added the hi-res display to the iPod Touch which means that images will use twice the amount of memory that they were using before. With the iPhone 4 they did it right and doubled up on the memory which helps a lot with the HD images taking up twice the amount of memory as the SD ones do. So anyway, back to the topic.
I needed some way to minimize the amount of memory utilization, so I started reading about sprite sheets and image sizes in the power of 2, etc… I found a neat utility called Zwoptex to create sprite sheets of all my images. This ended up helping me quite a bit, not only did it reduce the amount of disk space but it also reduced the amount of memory being used. At this time I was able to get my memory utilization down to about 90MB. To me, this is still quite high and I was not satisfied with the result, so I continued to look for a solution. I started reading about PVR’s and how fast they load and then I read about compressed PVR’s. Next, I needed to figure out how to use these PVR’s to lower my memory utilization and speed up my loading times.
I found an awesome app called TexturePacker which runs natively on Mac OS X. TexturePacker is a very similar tool to Zwoptex in that it creates sprite sheets from images but is very different and far more advanced when it comes to optimization. Long story short, I was able to use TexturePacker to create *.pvr.ccz sprite sheets for HD and SD images and reduced my memory utilization down to 50MB… WOW.. Now that is a lot better then the 130MB I started with. What I’d like to do now is present a tutorial on the usage of TexturePacker and walk you through step-by-step to get HD images loaded into TexturePacker, optimize them, publish them and finally write the code in Xcode to make them work. I’ll also share some best practices for memory management at the end of the tutorial.
Software you will need:
After you are done downloading the software above, you can follow the below steps to install TexturePacker and start up the Demo Project
If you haven’t downloaded Texture Packer yet, you can download it here. After the download has completed you can double click on the DMG file so that it mounts a disk image. The disk image contains the Texture Packer installer package. The screen should look like the screen shot below:
Double-Click the TexturePacker Package File and you will see the install screen, like the one below:
From there just follow all of the prompts until Texture Packer has completed the install process. You will find Texture Packer within your applications folder. Go ahead and launch Texture Packer. You will get the following screen:
Unless you’ve purchased a license you should choose Essential. The main difference is that with the Essential (Free Version) anything you export will be exported in red. In the next section I will give a brief overview of Texture Packer and the features we will use the most.
Note: All typos within the installer have been fixed since version 2.1.3
Referring to the screen shot above I used the Import Sprites button to import a selection of sprites to work with. Once I imported the sprites, Texture Packer automatically adjusts the sprite sheet size to fit the 3 sprites I imported. If you look to the bottom right of the application on the status bar, Texture Packer displays the size of the resulting sprite sheet and the amount of memory it will consume. In this case with the above images, my sprite sheet will be 128×128 and consume 64 kB of memory. 64kB of memory isn’t a whole lot but lets go ahead and do some optimization anyway and see if we can cut down on memory usage.
On the left hand side of the app you will see the Texture Settings menu that is divided into 3 categories; Geometry, Layout and Output. Scroll down to Output and find the Image format setting. The default for this setting is RGBA8888 which results in a sprite sheet with the highest quality and the most memory usage. Change this setting to RGBA4444 and watch what happens to the memory usage. 32kB is what the memory usage is now… WOW we just cut memory usage in half but at the cost of quality. Why? The reduced quality comes from taking a 32-bit image and converting it to a 16-bit image. Make sense?
Ok, lets fix the quality to make it look a little better. Two fields down, you’ll see Dithering. The default Dithering setting is NearestNeighbour which makes for some ugly gradients when going from 32 to 16-bit. Go ahead and change this to FloydSteinberg+Alpha and watch in amazement as your gradients start to look like gradients again. You may notice that this results in your sprites looking a bit noisy but remember, we are working with hi-res images here and every 4 pixels will equal 1 point so the image should look pretty sharp, at least that’s what I’ve experienced.
Let’s take a minute to go over the Output Category that’s in the Texture Settings Menu:
- Data Format – This setting is for defining in what format the sprite sheet data should be processed in. We need to select cocos2d for this. What this will do is generate a plist file that we will load into frame cache a little later.
- Data File – This will be the output location and name of the data file (plist file for cocos2d) You don’t need to set this as it will automatically be filled when you set the Texture File
- Texture Subpath – Not sure what this is for, I’ve never used it
- Trim sprite names – Leave this unchecked, I’m not sure what this is used for
- Texture Format – Here you will choose the output format of your sprite sheet. You can choose any format you like, they are all compatible with cocos2d but I recommend Compressed PVR (.pvr.ccz). This will give you the most compression and pretty quick load times.
- Image format - This is where we will get most of our optimization from. For most of the sprite sheets we create we should choose RGBA4444 as it will give you the best result. RGBA4444 is used for sprites with transparency’s. If you have a sprite that doesn’t use any transparency you should use RGB565. If you have a sprite sheet that absolutely needs to have the highest quality then use RGBA8888 but we aware that this will result in high memory use, especially if your sprite sheet is 2048 x 2048.
- Texture File – This is where you would set the name of your texture file. Click on the browse button to select your location and then give a name. If you are working with hi-res images be sure to add -hd at the end of the filename, you’ll see why, later.
- Dithering – I covered this earlier but just to re-cap, if you are using RGBA4444 you should use FloydSteinberg+Alpha and if you are using RGB565 then use FloydSteinberg
- Premultiply alpha – This is used to limit the amount of artifacts and possible thin black borders around your sprites when sprite anti aliasing is on. Also semi-transparent pixels might get too dark without this setting. If this is enabled be sure to add the following to your code:
- AutoSD – This is one of my favorite features of TexturePacker. What this little nifty checkbox does is automatically create a low-res sprite sheet and plist file for you but you have to make sure that you named your Texture file with a -hd at the end.
A Note from the author of TexturePacker: Whenever possible, you should use Add Folder to import your sprites because this uses smart folder. Every time you add sprites to the folder and update your sprite sheet it re-scans the contents of the folder and adds all sprites. This makes sprite handling much easier than adding single sprites.
Ok, so now we have our sprites imported and have everything optimized. Next we will talk about Publishing.
Publishing Sprite Sheets:
Before you click on the Publish button be sure that you’ve got all of your settings configured the way you want them. Here’s a quick step-by-step re-cap of the steps above:
- Import sprites either by using the Add Sprites or the Add Folder button.
- Set Data Format to cocos2d
- Set Texture format to Compressed PVR (.pvr.ccz)
- Set Image format to RGBA4444
- Set Texture file to something-hd
- Set Dithering to FloydSteinberg+Alpha
- Check AutoSD
With all of the above completed go ahead and click on the Publish button. Texture Packer will now export your hi-res and low-res sprite sheets and associated plist data files.
You should have something similar to the following screen shot:
There isn’t too much to say about publishing, the next section will cover how to get your sprite sheets to work with cocos2d.
Writing The Code:
After publishing your sprite sheets with Texture Packer, the next and last step would be to add this into your project and get them to show up in your scene. I’ll be walking you through adding your sprite sheets to your project and showing you code examples of how to make the best use of your new sprite sheets.
Open up Xcode, create a new cocos2d Project from one of the cocos2d templates and copy the 2 sprite sheets and 2 plist files that were exported from TexturePacker into your Resources folder within your Xcode project, make sure that copy files is checked.
Once the sprite sheets and plist files have been added go ahead and click on your HelloWorldScene.m and find your init method. Once you’ve located your init method replace what’s inside the if statement with the following lines of code:
[CCTexture2D setDefaultAlphaPixelFormat:kCCTexture2DPixelFormat_RGBA4444]; CCSpriteBatchNode *spritesDemoNode; spritesDemoNode = [CCSpriteBatchNode batchNodeWithFile:@"demosprite.pvr.ccz"]; spritesDemoNode.tag = 805; [self addChild:spritesDemoNode]; [[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"demosprite.plist"];
The code above does the following:
- Sets the current Pixel format to RGBA4444 to match that of our sprite sheet that we set in TexturePacker
- Creates a sprite batch node using the Compressed PVR
- Sets a tag ( has nothing to do with texture packer but I use tags for other reasons )
- Adds the node as a child to your current Layer
- Adds the sprite frames to cache from the plist file that was exported by Texture Packer
Next we need to create a CCSprite from the frames that are in cache, we do this with the following code:
CCSprite *spriteDemo = [CCSprite spriteWithSpriteFrameName:@"fireball.png"]; spriteDemo.position = ccp(size.width/2, size.height/2); spriteDemo.tag = 1; [self addChild:spriteDemo];
The above code does the following:
- Creates a sprite from the frames in cache. In this case I had an image named fireball.png that was one of the images that was imported into Texture Packer. When Texture Packer creates the plist file it uses the names of your sprites for the frame names, which makes it easy to use.
- Next I am setting the position to the center of the screen. size is a variable that I’ve setup that has the height and width of the screen as properties.
- Again I am setting a tag, not something you have to do
- Last we are adding the new sprite to our layer.
If all went well and you’ve followed all of the above directions then you should be able to build your project and see your sprite on the scene. Granted, this is more work then copying individual PNG’s into your project and just creating sprites from the PNG’s but that is a big waste of memory and will eventually crash your app. Remember, with Texture Packer I was able to reduce my memory to more then half of the original memory utilization even using Zwoptex did not make a huge improvement with memory usage. I would definitely recommend Texture Packer to anyone that is interested in optimizing memory.
If anyone has any questions or comments please feel free to leave them. If anyone has any more optimization tips, please share, I would love to hear them and I’m sure everyone else would appreciate it as well.