Sprite Sheets

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.

Sure, for example morphing, or warping as its sometimes called, but there are tools in the works.....

Evil laugh

muhahaaahaaaa

Pokes Lucid

Maybe when cropped sprite sheets are supported, you'll all see what I am up to! (*nudge nudge Ashley*)

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! :)Sure, there's pro and cons for either way. But it's best to decide what is the best for the cpu and memory. If that means more work on the developing end, so be it. There's nothing worse then purchasing or even playing a free game just to find out it could have been optimized better.

There's nothing worse then purchasing or even playing a free game just to find out it could have been optimized better.

You're right, people would be upset they didn't pay for it <img src="smileys/smiley2.gif" border="0" align="middle" />

Seriously though, every game can be optimized better, especially the ones you've paid for. They figure "Well, we could waste a weeks worth of budget to make it run on lower end machines, or we can encourage/force people to upgrade to newer hardware, at no cost to ourselves."

Although someone making free games may not be paid for it, they would also lose valuable time making minor improvements most users won't notice.

To be honest I don't actually see much efficiency advantage over using sprite sheets. C2 can PNGCrush files to absolutely minimise the PNG filesize, and modern graphics cards can use non-power-of-two textures so split frames don't use more VRAM than a single sprite sheet, as well as being able to render 2D things so fast that there's nothing to be gained by rendering from one texture instead of many. So what other efficiency gains are you looking for by using sprite sheets?

To be honest I don't actually see much efficiency advantage over using sprite sheets. C2 can PNGCrush files to absolutely minimise the PNG filesize, and modern graphics cards can use non-power-of-two textures so split frames don't use more VRAM than a single sprite sheet, as well as being able to render 2D things so fast that there's nothing to be gained by rendering from one texture instead of many. So what other efficiency gains are you looking for by using sprite sheets?

Huge difference when using sprite sheets. I can take 262kb of images, run them through a sprite sheet editor (I use my own) and get a 156kb sprite sheet. Then I run it through ImageAlpha and ImageOptim (both are Mac only) and get a 49kb sprite sheet. I just wipe off 213kb and my images look exactly the same as before. Now just imagine doing that to all your images. You're saving a lot of memory, faster loading times, and smaller executable. ;)

Now if we can just get everyone using ogg audio. Small file sizes and better quality then mp3.:D

> To be honest I don't actually see much efficiency advantage over using sprite sheets. C2 can PNGCrush files to absolutely minimise the PNG filesize, and modern graphics cards can use non-power-of-two textures so split frames don't use more VRAM than a single sprite sheet, as well as being able to render 2D things so fast that there's nothing to be gained by rendering from one texture instead of many. So what other efficiency gains are you looking for by using sprite sheets?

Huge difference when using sprite sheets. I can take 262kb of images, run them through a sprite sheet editor (I use my own) and get a 156kb sprite sheet. Then I run it through ImageAlpha and ImageOptim (both are Mac only) and get a 49kb sprite sheet. I just wipe off 213kb and my images look exactly the same as before. Now just imagine doing that to all your images. You're saving a lot of memory, faster loading times, and smaller executable. ;)

I think what Ashley is getting at is that it doesn't matter how you import the images, they are stored in the capx file itself as PNG's, and instead use Construct 2's method of compression when the game is exported. It doesn't matter whether your sprite images have 1000 pixels of empty space on the sides or not, Construct 2 will crop and compress to the same size.

Edit: I just saw that he was also saying that whether the animation images are seperate objects or a single large image, there is little to no performance gain either way.

I would assume that drawing the seperate objects (of the same image as shown in the Sonic example), would actually draw faster than seperate animation frames, as the image raw data does not change as it is repositioned and sized on the screen.

Edit: I just saw that he was also saying that whether the animation images are seperate objects or a single large image, there is little to no performance gain either way.

Me? If so, you misunderstood. I say that there is little difference in file size when cropping dead space. As long as it's minimal to begin with. Which it should be. ;)

Comparing the "blade" enemy from Space Blaster, which is a 16 frame animation, it comes out:

144kb PNGCrushed as 16 separate files after export

126kb as a single sprite sheet

So that's a saving of about 12% in filesize. I agree there is a saving to be had, but while we're really stretched for time over loads of important features that don't yet exist at all, I'm not prepared to spend time on this for an "invisible" improvement while there are much-missed features like families. So maybe this can be done some time in future.

Comparing the "blade" enemy from Space Blaster, which is a 16 frame animation, it comes out:

144kb PNGCrushed as 16 separate files after export

126kb as a single sprite sheet

So that's a saving of about 12% in filesize. I agree there is a saving to be had, but while we're really stretched for time over loads of important features that don't yet exist at all, I'm not prepared to spend time on this for an "invisible" improvement while there are much-missed features like families. So maybe this can be done some time in future.

I got it down to 29kb here in a sprite sheet. <img src="smileys/smiley2.gif" border="0" align="middle" />

Oh and graphics cards still work in power of two. Just because they are able to load non-power of 2 images doesn't mean that's all it doing. Those blade images are getting padded by the graphics card to 128x128 because that's the next power of 2.

So making HTML5 games which don't have hardware acceleration, it's best to optimize as much as possible.

I wanted to explain more on my above post in case I confused anyone.

Think of ASM. It's nothing but a cover for machine code. Graphics cards are the same way. They see nothing but power of 2. Now some years ago, graphic card developers made it so you could load non-power of 2 images. But the graphics card still has to secretly pad your image(s) to read it properly. It's impossible for the graphics chip to see any different unless you trick it. And that's what happen some years ago. It's best to stick with 2, 4, 8, 16, 32, 64, 128, 256, and so forth. And it's ok to use 128x128 or even 64x128. Just as long as you stick with power of 2 numbers. Because the graphics card will do it anyway.

I got it down to 29kb here in a sprite sheet.

Would you care to share how you beat PNG compression by over 75%? That's a stunning saving. If it's easily possible why isn't the PNG image compressed that small to begin with?

h and graphics cards still work in power of two.

Have you got a reference for that? I couldn't quickly find a reliable reference, but the OpenGL spec doesn't say what implementors should do, so it might be driver-dependent.

> I got it down to 29kb here in a sprite sheet.

Would you care to share how you beat PNG compression by over 75%? That's a stunning saving. If it's easily possible why isn't the PNG image compressed that small to begin with?

h and graphics cards still work in power of two.

Have you got a reference for that? I couldn't quickly find a reliable reference, but the OpenGL spec doesn't say what implementors should do, so it might be driver-dependent.

Don't forget about PNG8 w/alpha. <img src="smileys/smiley2.gif" border="0" align="middle">

I simply used my own sprite sheet maker which creates small png images and used ImageAlpha and ImageOptim. Those are Mac only apps but I'm sure you could find similar on Windows. The image has 128 colors with alpha but looks the same as the original. See link.

blade.png

As for the reference. Let me look it up again. It's been a while since I read it and have to remember where.

Don't forget about PNG8 w/alpha.

Unfortunately reducing the color depth is not something Construct 2 can do automatically. Construct 2 must always work in the general case, and many images look terrible after color depth reduction. So that's not something we can always apply to reduce filesize.

We might be able to add compression settings in future, but for now everything has to be PNG32, and as you saw the savings for that are only around 12%. If you are that concerned about reducing filesize after export, you can run your own tools over the exported PNG images, and you should see similar gains.

> Don't forget about PNG8 w/alpha.

Unfortunately reducing the color depth is not something Construct 2 can do automatically. Construct 2 must always work in the general case, and many images look terrible after color depth reduction. So that's not something we can always apply to reduce filesize.

We might be able to add compression settings in future, but for now everything has to be PNG32, and as you saw the savings for that are only around 12%. If you are that concerned about reducing filesize after export, you can run your own tools over the exported PNG images, and you should see similar gains.

I was just trying to help explain sprite sheets and optimization. <img src="smileys/smiley2.gif" border="0" align="middle" />