Sprite Sheets Tools and Formats

Sprite Sheets (Texture Atlas)

A sprite sheet (also called a "texture atlas") is a method of combining multiple images into a single file to improve performance and, in some cases, save memory and disk space. The key components are the combined image containing all the assets, and a text file that indicates the position of each asset (along with some additional information).

The easier way to create sprite sheets is using tools:

Free tools

• SpriteSheet Packer. Open source, it supports polygon packing.
• Free Texture Packer. Web based.
• Free Sprite Sheet Packer. Web based.
• Tool to convert JSON hash to PLIST v3 (Thanks to Rogerup)

Paid tools

• Texture Packer. Commercial product, but it's the most complete solution.

Support for custom sprite sheet formats

Default sprite sheet format is PLIST v3. A description of the format may be found here. This is the format that some of the mentioned applications outputs when you select the "Cocos2d-x" option. But Axmol can use any type of sprite atlas, not just PLIST, so tools that output formats other than PLIST can also be used. This is how to add the support for parsing other formats:

• Custom sprite sheet format reader is created by implementing the SpriteSheetLoader interface, then registering this implementation by calling SpriteFrameCache::registerSpriteSheetLoader().
• Custom SpriteSheetLoader must have a unique identifier, which is assigned by using the SpriteSheetFormat::CUSTOM as the base value. For example, MyFormatId = SpriteSheetFormat::CUSTOM + 10.
• In cpp-tests, SpriteFrameCache test has an implementation of a JSON sprite sheet format loader, implemented with the name GenericJsonArraySpriteSheetLoader. Use the GenericJsonArraySpriteSheetLoader and the default PlistSpriteSheetLoader as examples on how to implement the SpriteSheetLoader interface.
• Sprite sheets must always contain unique identifiers for the sprite frames. Loading more than one sprite sheet that uses the exact same frame identifers will result in undefined behaviour. There are several ways to handle this, one being to prefix the graphic filenames, so for example, if two different files are named image1.png, one being for scene1 and another for scene of a game, then you would name them scene1_image1.png, scene2_image1.png. The other, and possibly the better method, is to use sub-folders folders to differentiate between frame names, such as scene1/image1.png and scene2/image1.png, and ensure that the sub-folder name is not stripped out during sprite sheet creation.