Generating Sprite Sheets at Runtime

Sprite sheets are sort of annoying to maintain. It would be nice if sprite batching "just worked". This is especially true if we add automatic batching. Ideally you should just be able to dump .png files in the project and still get the performance benefits of a hand created (or scripted) sprite sheet. I see two mutually inclusive ways to do this.

Static atlasing: (medium) Given a list of images png/jpeg images, it's pretty inexpensive to atlas them as a loading step. I wouldn't expect this to be much more expensive than loading them regularly. This would work much like [CCSpriteFrameCache addSpriteFramesWithFile:]. Instead of a .plist file, you give it a list of files or possibly a directory to atlas. This would be fairly easy to implement. We might even be able to steal some SpriteBuilder code to do this.

Dynamic atlasing: (probably hard) This is much more ambitious, but potentially a killer feature. A developer could enable this mode and Cocos would create incremental atlases. Each time a texture is loaded, it would be loaded directly into an existing atlas. The atlasing would be transparent to the developer. It might cause stuttering if loading a texture causes the atlas to be repacked, but combined with auto batching this could be huge for most Cocos games. The downsides of it are the lack of control. The more complicated a game gets, the more likely it is to benefit from hand organized sprite sheets. This is when you might want to use static atlasing or externally generated sprite sheets.

.pvr files would again be left in the cold, but I don't feel bad about that since they are more of a power user feature for those that want more control anyway. Other things to consider are that it would need to be aware of texture object changes such as enabling mipmapping or changing the texture wrapping mode.

cocos2d / cocos2d-objc

Generating Sprite Sheets at Runtime #476