Why asset sheets?

[TheNavigat]

Hello there. I've been reading 4urentertainment's article over and over, Animating With Asset Sheets. It totally makes sense and I like it, but there's something confusing there. Why should I export the images using TexturePacker, why not just add them to the library and implement them using class declarations? And if I exported the asset sheet, how am I going to split the images?

It's the first time for me to work with asset/sprite sheets, so please be simple. I'm just lost, apparently. Thanks.

[MintPaw]

When you export with Texture Packer you get an XML file explaining how they're split, some frames works like Starling will automatically split them apart and even arrange them in animation by the start of the file name (e.g. "derp_001", "derp_002") etc.

Also Flash vector animation is painfully slow. Like PAINFULLY slow. Like 2fps on iPhone 5 kind of slow. Bitmap animations are much faster, plus they take up less filesize.

[TheNavigat]

At 7/10/13 12:43 AM, MintPaw wrote: When you export with Texture Packer you get an XML file explaining how they're split, some frames works like Starling will automatically split them apart and even arrange them in animation by the start of the file name (e.g. "derp_001", "derp_002") etc.

Also Flash vector animation is painfully slow. Like PAINFULLY slow. Like 2fps on iPhone 5 kind of slow. Bitmap animations are much faster, plus they take up less filesize.

But I can import the same images as bitmapData, not vector, importing the PNGs themselves I mean, and the filesize difference, I believe that wouldn't be much to even consider saving :/

[MintPaw]

Well also a big advantage is that that's how it's been done forever, you can find sprites and other resources in that format because that's the format we've used since the 1990's, Flash IDE will come and go, vector based SWFs will be forgotten, but images will still be a viable format for some time.

Also importing BitmapData like that requires you to make a blitter, it's hard and take a lot of time, Starling was ported from the iOS platform Sparrow, where the Flash IDE didn't exist.

Another downside of the Flash vector graphics is that you have to own Flash, suddenly making game development have a ~$500 price tag rather than it's current free-ness.

[TheNavigat]

At 7/10/13 01:23 AM, MintPaw wrote: Well also a big advantage is that that's how it's been done forever, you can find sprites and other resources in that format because that's the format we've used since the 1990's, Flash IDE will come and go, vector based SWFs will be forgotten, but images will still be a viable format for some time.

Also importing BitmapData like that requires you to make a blitter, it's hard and take a lot of time, Starling was ported from the iOS platform Sparrow, where the Flash IDE didn't exist.

Another downside of the Flash vector graphics is that you have to own Flash, suddenly making game development have a ~$500 price tag rather than it's current free-ness.

Aha, so, simply, asset sheets save the time of renaming the classes and importing them to the Flash library, so you just import one asset sheet, and the array takes care of the 50 sprites in there. Am I right so far? And yep, I know how bad vector graphics are..

[MSGhero]

At 7/10/13 01:30 AM, TheNavigat wrote: Aha, so, simply, asset sheets save the time of renaming the classes and importing them to the Flash library, so you just import one asset sheet, and the array takes care of the 50 sprites in there. Am I right so far? And yep, I know how bad vector graphics are..

The xml output can also specify things like registration points, scaleXY, rotation, etc depending on what exporter you use and where the graphics come from originally. Vector graphics do have their perks, but definitely not for times of poor cpu power/high cpu usage like mobile or games with thousands of things flying around.

[TheNavigat]

At 7/10/13 01:43 AM, MSGhero wrote:

At 7/10/13 01:30 AM, TheNavigat wrote: Aha, so, simply, asset sheets save the time of renaming the classes and importing them to the Flash library, so you just import one asset sheet, and the array takes care of the 50 sprites in there. Am I right so far? And yep, I know how bad vector graphics are..

The xml output can also specify things like registration points, scaleXY, rotation, etc depending on what exporter you use and where the graphics come from originally. Vector graphics do have their perks, but definitely not for times of poor cpu power/high cpu usage like mobile or games with thousands of things flying around.

I still don't understand. My question is, why should I use an asset sheet of PNGs with an XML/JSON and an exporter/slicer instead of importing them individually to Adobe Flash Pro's project library?

[MSGhero]

At 7/10/13 01:47 AM, TheNavigat wrote: I still don't understand. My question is, why should I use an asset sheet of PNGs with an XML/JSON and an exporter/slicer instead of importing them individually to Adobe Flash Pro's project library?

Because you'd have to type out and instantiate every single linkage name instead of instantiating one bmd and letting a for loop put everything where it needs to go.

[TheNavigat]

At 7/10/13 02:02 AM, MSGhero wrote: Because you'd have to type out and instantiate every single linkage name instead of instantiating one bmd and letting a for loop put everything where it needs to go.

Aha, so no performance difference then?

[MSGhero]

At 7/10/13 02:07 AM, TheNavigat wrote:

At 7/10/13 02:02 AM, MSGhero wrote: Because you'd have to type out and instantiate every single linkage name instead of instantiating one bmd and letting a for loop put everything where it needs to go.

Aha, so no performance difference then?

Instantiating 24 bmds to make an animation vs instantiating one would drop the framerate a bit, but that should be done at compile time anyway. And there's gotta be more memory used by the 24 than the one as far as overhead and stuff: imagine thousands of 1x1 bmds or one large bmd.

[TheNavigat]

At 7/10/13 02:14 AM, MSGhero wrote:

At 7/10/13 02:07 AM, TheNavigat wrote:

At 7/10/13 02:02 AM, MSGhero wrote: Because you'd have to type out and instantiate every single linkage name instead of instantiating one bmd and letting a for loop put everything where it needs to go.

Aha, so no performance difference then?

Instantiating 24 bmds to make an animation vs instantiating one would drop the framerate a bit, but that should be done at compile time anyway. And there's gotta be more memory used by the 24 than the one as far as overhead and stuff: imagine thousands of 1x1 bmds or one large bmd.

Well, in the end I'll splice it anyway to instantiate bitmapDatas out of it, if you've got them in the library, it's the same concept. You only replace bitmapDatas and by doing so the old ones have no reference and will be set to null.

Let me illustrate what I've understood in a simpler way.

Let's say we've got an asset sheet, 5 body parts. You'll have to instantiate 5 bitmaps, and then run a loop to copy each body part to a bitmapData, so you've got 5 bitmapDatas. Now you can move the thing.

On the other hand, using a library, you've got 5 bitmapData unique classes. You instantiate each one, and then add them to the 5 bitmaps. According to this, using library would even save more performance, because there's no bit copying.

I don't really know what's behind the scenes so I may be wrong, but even if there was some bit copying, then the performance is equal. Asset/Sprite sheets just get it more complicated by packing them and having some properties with rotation and stuff that need to be sliced..

[MSGhero]

At 7/10/13 02:24 AM, TheNavigat wrote: I don't really know what's behind the scenes so I may be wrong, but even if there was some bit copying, then the performance is equal. Asset/Sprite sheets just get it more complicated by packing them and having some properties with rotation and stuff that need to be sliced..

Ok I see. What I do is instead of literally "slicing" the bmd into smaller ones, I make an array of rectangles, each one representing a region of the bmd, where each sprite is. I've been using evenly-spaced, unrotated image--all of the rectangles are the same width and height--so it'll vary a bit here. Either way, an "animation" is me telling copyPixels which rectangle to use as the sourceRect parameter next. The sourceBMD is always that big png that you loaded in.

So for a character walking, say rectangles 0-4 make up his walk cycle. I'd have an update method handling when to move on to the next rectangle and a render method to actually do copyPx. It starts off using rect0 as sourceRect, then rect1 after enough time has passed, and so on. This is one place where the xml is handy, defining these rectangles.

As far as the asset sheets, you could have like armRect, headRect, torsoRect, etc which get plugged into copyPx or draw for a matrix transform. The sourceBMD is still the same big png.

[OmarShehata]

The main reason to use asset sheets is if you're not using flash in the first place. As MSGhero pointed out, it's a just a platform independant way to animate things.

[MSGhero]

At 7/10/13 02:41 AM, 4urentertainment wrote: The main reason to use asset sheets is if you're not using flash in the first place. As MSGhero pointed out, it's a just a platform independant way to animate things.

Mint said that :)

[TheNavigat]

At 7/10/13 02:37 AM, MSGhero wrote:

At 7/10/13 02:24 AM, TheNavigat wrote: I don't really know what's behind the scenes so I may be wrong, but even if there was some bit copying, then the performance is equal. Asset/Sprite sheets just get it more complicated by packing them and having some properties with rotation and stuff that need to be sliced..

Ok I see. What I do is instead of literally "slicing" the bmd into smaller ones, I make an array of rectangles, each one representing a region of the bmd, where each sprite is. I've been using evenly-spaced, unrotated image--all of the rectangles are the same width and height--so it'll vary a bit here. Either way, an "animation" is me telling copyPixels which rectangle to use as the sourceRect parameter next. The sourceBMD is always that big png that you loaded in.

So for a character walking, say rectangles 0-4 make up his walk cycle. I'd have an update method handling when to move on to the next rectangle and a render method to actually do copyPx. It starts off using rect0 as sourceRect, then rect1 after enough time has passed, and so on. This is one place where the xml is handy, defining these rectangles.

As far as the asset sheets, you could have like armRect, headRect, torsoRect, etc which get plugged into copyPx or draw for a matrix transform. The sourceBMD is still the same big png.

Aha, now I got it! In my case then, it wouldn't really differ because what I'm using is "assets". The "5 body parts" will always stay on screen, but using blitting, specially for a large number of "shapes", then using a sheet and copyPx would perfectly reduce the performance! Am I right? :)

[TheNavigat]

At 7/10/13 02:41 AM, 4urentertainment wrote: The main reason to use asset sheets is if you're not using flash in the first place. As MSGhero pointed out, it's a just a platform independant way to animate things.

Aha, I see. Thanks a lot, now I got it :)

[MSGhero]

I read about the dragonbonesframework today, and it's exactly this, but from movieclips in flash pro if you have it. It's built off starling, so you have the gpu to improve rendering.

[64base]

At 7/20/13 06:45 PM, MSGhero wrote: I read about the dragonbonesframework today, and it's exactly this, but from movieclips in flash pro if you have it. It's built off starling, so you have the gpu to improve rendering.

Gave it a shot and I can truthfully say that it is much more superior than what I've made (which took an hour anyways).

I just recently decided to use DragonBones + Starling + Feathers and I can honestly say that all of these libraries in conjunction make game development a breeze! Try it out guys!

And to OP: these libraries will take care of all your problems (i.e., pivot points, caching and asset management, animations with easing and interpolation and rendering!) give it a shot, you'll be surprised how easy to use they are!

[TheNavigat]

At 7/21/13 09:10 AM, 64base wrote: And to OP: these libraries will take care of all your problems (i.e., pivot points, caching and asset management, animations with easing and interpolation and rendering!) give it a shot, you'll be surprised how easy to use they are!

I'll give it a shot when I'm creating a similar thing again. Also, that reminds me with the first time I used Box2DFlash. I owe the guy my whole life..

[TheNavigat]

At 7/21/13 10:04 AM, Innermike wrote: Kids these days and their fancy animation methods, there is nothing wrong with just doing it the old fashioned way, for most cases it makes a lot more sense.

If the old method is perfect, why not? Unfortunately, for my case, it's not.

On a side-note, are you saying that asset sheets animations is not old-fashioned?.. I believe that's as old as blitting, no evidence, just logical thinking. I believe they first thought about animating the assets by code before they thought "Why don't we just replace the bitmapData every frame?", just my beliefs, though.

[MSGhero]

At 7/21/13 12:44 PM, Innermike wrote: More draw calls for individual parts as opposed to fewer calls of readily baked images -> more intensive -> harder to run on more primitive hardware -> no it wouldn't be as old. That being said it was more of a statement on prevalence rather than age specifically.

The benefit is that you're going from a huge spritesheet to 7 images. In an example the spritesheet was 7-800kb and the asset sheet was like 12 or so, maybe 20. And it's leveraging the gpu, so more drawing calls aren't too bad.

[TheNavigat]

At 7/21/13 12:44 PM, Innermike wrote: More draw calls for individual parts as opposed to fewer calls of readily baked images -> more intensive -> harder to run on more primitive hardware -> no it wouldn't be as old. That being said it was more of a statement on prevalence rather than age specifically.

Mmmm.. Yea, seems logical!

My point was that it's rare to actually reap substantial benefits from a more complicated system than is required (I think someone else made the same point earlier come to think of it). What exactly is it you're doing anyway?

I had a problem with "popping" animations. This project is big, so I wanted every single thing to be made as perfect enough as possible. I had already read the article earlier, and one of the bold pros were how easy you can implement a smooth transition between animations, so I just went for it!