Hi,
This weekend is actually the first time I've used any of the atlas sprite stuff as previous projects either didn't have a lot of sprite animation, or used custom techniques to draw a lot of sprites on the screen. After a bit of experience with the internal system and the Zwortex system, I'm left with some ideas and questions regarding the current design. A quick overview, for those who haven't used both systems:
Cocos Atlas Sprite
+ optimized drawing for rendering many of the same sprites to the screen
- restrictions on parenting structure
- no parallax support
- doesn't handle offsetting non-uniform scaled sprites
- no automatic loading/creation of sprite atlases
Zwortex Atlas Sprite:
+ automatic generation and loading of atlas frame data
+ handles offsets for non-uniform scaled sprites
+ can be parented like any other cocos node
+ can have multiple texture pages per sprite
- less cocos-like in it's implementation
- doesn't support negative scale correctly (offsets sprite)
- different animation behavior than cocos
- runs at variable frame rate (BAD!!!) based on rendering speed
- assumes looping
Now, I ended up using the zwortex code and adding support for a fixed, settable frame rate as well as a looping bool. I haven't fixed negative scale yet but will. I'm happy to share these changes if people want them. Overall, the system works for what I'm doing but it got me thinking that it would be nice if we could get the benefits of both systems in the official cocos one. Here's what I'm thinking:
Atlas sprite manager currently manages the texture of the atlas sprite and optimizes the drawing of many sprites into the same draw call. This optimization is what causes the most restrictions on atlas sprites (parenting, z-order, only one sprite sheet). We should decouple this relationship so that the functionality for drawing things from an atlas page in an efficient manner is only used when an atlas sprite is attached to a manager, while still allowing an atlas sprite to exist and draw like a normal cocos node.
This would allow you to use atlas sprites for efficient packing of texture data, optimized loading, and all there other goodness while opting in for a draw-call optimized version when needed. It would also make the process of getting started with atlas sprites much easier, since a new user could treat them like a traditional cocos node until they need to use a more optimized version. In many cases, where you have a single character running around, the draw optimization adds unnecessary complexity and limitations for no gain.
Additionally, we should consider standardizing on a plist format for the frame data. Being able to load this data in with a single command, ala the ZWortex tool, is really awesome. I don't know if he'd consider donating that tool as an air app (or better yet, source code) to the cocos community, but having us all on one standard would really rock.
Also, the cocos version absolutely needs to support offset positions. It's extremely limiting not to support them, and either means hacking the code to manually support them from outside the library, or wasting tons of texture space (which is part of the point of using an atlas).
Now, I usually don't get many responses to these architecture posts - but hopefully you guys have some opinions on this stuff, tips, additional needs, etc that I haven't come across in my short time with the system(s).
