Sprite Sheets

Any plan for supporting sprite sheet animations, as generated by Texture Packer ?

My character art frames are rendered out onto a standard size image, though the actual content changes size and shape from frame to frame considerably. (And there is a ton of it.)

Using Texture Packer is essential.

Thanks

Pepper

r51 added a 'import sprite sheet' option to the animations editor Frames pane. However, frames must be laid out in a regular grid, because C2 cuts up sprite sheets in to rectangles. C2 doesn't support irregularly laid out frames like TexturePacker seems to do yet I'm afraid. Perhaps it has an option to use a regular grid?

Thanks for the response Ashley.

Yeah, you can use regular/same size cells in a Texture Packer sprite sheet, but as I am sure you know, this is really inefficient.

In my case especially, where I have an animated fighting game character that kicks, punches, jumps, ducks, and so forth so that in each frame, the art changes shape and position dramatically. I would have to have really large cells with tons of dead space to accommodate.

If you crop each frame that you import, it will remove any wasted space. (You might need to wait until we have hotspots for this to work smoothly though.) Once each frame is cropped, AFAIK the download size is not much more than a sprite sheet and the VRAM usage is about the same as well. Modern graphics cards support non-power-of-two textures so there's no memory wasted by having lots of different frames.

Cool. I'll give it a try.

Will install 51 tonight.

Thanks for the feedback!

Thanks for the response Ashley.

Yeah, you can use regular/same size cells in a Texture Packer sprite sheet, but as I am sure you know, this is really inefficient.

In my case especially, where I have an animated fighting game character that kicks, punches, jumps, ducks, and so forth so that in each frame, the art changes shape and position dramatically. I would have to have really large cells with tons of dead space to accommodate.

A sprite sheet with cropped frames is literally only a few kb larger then one that does not. Besides that, Texture Packer creates bloated pngs. Try a different program. Also, never have your character or object change positions in your sprite sheet, per frames. Any change in position should be done by code or game editor function. ;)

sprite sheet with cropped frames is literally only a few kb larger then one that does not.

That depends on how your graphics are created. E.g. if you have a character that is dodging and attacking with a sword it might be a *big* difference if frames are cropped or not.

exture Packer creates bloated pngs

Currently the file size is about 15% bigger then when using opting. This will be fixed with the 3.0.0 release.

lso, never have your character or object change positions in your sprite sheet, per frames. Any change in position should be done by code or game editor function.

You have several cases with animations where this is exactly not what you want to do. You want to keep the anchor point steady while the animation moves around it...

I don't know much about Texture Packer, but I can say:

• Construct 2 stores all images as PNG, so transparency around an image should all be compressed away. Still, it's good practice to crop them because images are stored as bitmap in memory for drawing, so the extra space means more memory used. Right now C2 also only has bounding box collision so empty space around the player will also collide, but you can work around that with a hidden collision sprite, or just wait until we add collision polygons.
• You have the option to recompress PNGs (via PNGCrush) on export, making them even smaller.

if you have a character that is dodging and attacking with a sword it might be a *big* difference if frames are cropped or not.

...snip...

You want to keep the anchor point steady while the animation moves around it...

Correct. Posemotion: Imagine a standing character crouching down to do a foot sweep, standing, then doing a high roundhouse kick. The size of the art in the frame changes dramatically.

Right now C2 also only has bounding box collision so empty space around the player will also collide, but you can work around that with a hidden collision sprite, or just wait until we add collision polygons.

I look forward to seeing this implemented; right now the bounding box collision issue is keeping me from really diving into Construct2 full force. In the meantime I am working on my design, art, and C2 tutorials.

I don't want to sound like an advertisement for Texture Packer, but I bring it up because it has a lot of nice features and was so easy to use with Corona SDK. (I ditched Corona due to their sprite libraries being completely broken.) I was hoping for similar interop with C2.

FWIW: I run my pngs through Photoshop's "Save for Web" interface to trim them up.

Thanks again for the great discussion.

sprite sheet with cropped frames is literally only a few kb larger then one that does not.

That depends on how your graphics are created. E.g. if you have a character that is dodging and attacking with a sword it might be a *big* difference if frames are cropped or not.

Then you would save some memory and the sword (possibly with arm too) on it own image. This would be for a large sword anyway. As there would definitely be a large amount of transparent image if it was all in one.

exture Packer creates bloated pngs

Currently the file size is about 15% bigger then when using opting. This will be fixed with the 3.0.0 release.

Sometimes even higher but can then be loaded and saved out of another program to reduce.

lso, never have your character or object change positions in your sprite sheet, per frames. Any change in position should be done by code or game editor function.

You have several cases with animations where this is exactly not what you want to do. You want to keep the anchor point steady while the animation moves around it...You have to be kidding me? Animating by code will save more space then within frames. Anything can be animated in a frame but x/y coordinates, zooming, rotating, and so forth is much better by code.

> sprite sheet with cropped frames is literally only a few kb larger then one that does not.

> That depends on how your graphics are created. E.g. if you have a character that is dodging and attacking with a sword it might be a *big* difference if frames are cropped or not.

Then you would save some memory and the sword (possibly with arm too) on it own image. This would be for a large sword anyway. As there would definitely be a large amount of transparent image if it was all in one.

> exture Packer creates bloated pngs

> Currently the file size is about 15% bigger then when using opting. This will be fixed with the 3.0.0 release.

Sometimes even higher but can then be loaded and saved out of another program to reduce.

> lso, never have your character or object change positions in your sprite sheet, per frames. Any change in position should be done by code or game editor function.

> You have several cases with animations where this is exactly not what you want to do. You want to keep the anchor point steady while the animation moves around it...You have to be kidding me? Animating by code will save more space then within frames. Anything can be animated in a frame but x/y coordinates, zooming, rotating, and so forth is much better by code.

I see what you're both trying to say here. I think it's a common mistake to try to move an object using animations, and it most often wont work. But if you have, say, a little power up that orbits around your character yet is purely an effect (it doesn't shoot or shield damage or anything), then it's better to move it via animations, for instance:

<img src="http://media.giantbomb.com/uploads/0/1264/199592-son2_32_super.gif" border="0" />

the little balls rotating around robotnik (dr. eggman for some of you) are best implemented as animations, not as actually changing positions via code.

Yes Fimbul, there are certain situations that you can't avoid. Which is fine.

But lets say you have a character who jumps, spins, and then lands. I would not animate his spin in a sheet. That would give you approximately 9 to 14 more images then needed. Just create one image of the character rolled up. Then when it's time for him to spin, clip that frame and do it by code. You just save your sprite sheet from being larger then needed. And also achieved a better frame rate of your spin. Instead of only getting maybe 10 fps on the spin.

As for an actor with a large sword. Let's say you create his right arm in its own sprite sheet with sword. And the character in it's own sprite sheet. You just saved your self a bunch of dead space in your single sprite sheet and you have more animating and rotation options with the arm and sword sheet.

Anyway, just trying to help. Not trying to start anything here. ;)

I'm not sure I agree with your Robotnik example. Each additional frame would add the same amount of vram as the first, and be static. Not to mention the issues of collision detection, and deltatime.

Where in code you would only use vram equal to the first frame, and be able to do much better collision detection with randomization, etc.

On the other hand the code method is moot at this point, as there is no z currently.

Anyway, just trying to help. Not trying to start anything here. ;)

Oh, certainly. I understood what you said. A common situation is when people try to implement that delay on a missile between you firing it and it actually starting its engines via animations, resulting in glitchy collision/hit detection and memory waste. Character jumps via animations are glitchy just as bad.

I used the example to show there are a couple rare situations that you CAN use animations

I'm not sure I agree with your Robotnik example. Each additional frame would add the same amount of vram as the first, and be static. Not to mention the issues of collision detection, and deltatime.

Sure, but you can see where I'm getting at. Maybe in your game, you have little balls floating around you for each 1 extra life that you have, or maybe your fairy companion (that does nothing) rotates around you. You get my point. The situations where it's ok to do movement via animations are very limited, but they do exist.

Maybe it's one of those situations where there are pros and cons either way, and you just have to decide what's right for you! :)