Sprite Sheets

Discussion and feedback on Construct 2

Post » Sat Aug 27, 2011 7:55 pm

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?
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Mon Aug 29, 2011 6:01 am

[QUOTE=Ashley] 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?[/QUOTE]
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.:DPoseMotion2011-08-29 06:07:06
B
18
S
5
G
2
Posts: 16
Reputation: 2,012

Post » Mon Aug 29, 2011 6:21 am

[QUOTE=PoseMotion] [QUOTE=Ashley] 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?[/QUOTE]
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. ;)[/QUOTE]

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.Jayjay2011-08-29 06:26:29
"Construct 4 lets YOU make advanced games! (maybe)" Construct Classic - Examples Kit
B
86
S
28
G
13
Posts: 2,092
Reputation: 15,009

Post » Mon Aug 29, 2011 6:31 am

[QUOTE=Jayjay]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.[/QUOTE]

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. ;)
B
18
S
5
G
2
Posts: 16
Reputation: 2,012

Post » Mon Aug 29, 2011 1:37 pm

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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Mon Aug 29, 2011 7:51 pm

[QUOTE=Ashley] 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.[/QUOTE]
I got it down to 29kb here in a sprite sheet.

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.
B
18
S
5
G
2
Posts: 16
Reputation: 2,012

Post » Mon Aug 29, 2011 8:08 pm

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.
B
18
S
5
G
2
Posts: 16
Reputation: 2,012

Post » Mon Aug 29, 2011 8:23 pm

[QUOTE=PoseMotion]I got it down to 29kb here in a sprite sheet.[/quote]
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?

[quote]Oh and graphics cards still work in power of two.[/QUOTE]
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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Mon Aug 29, 2011 8:38 pm

[QUOTE=Ashley] [QUOTE=PoseMotion]I got it down to 29kb here in a sprite sheet.[/quote]
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?

[quote]Oh and graphics cards still work in power of two.[/QUOTE]
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.[/QUOTE]
Don't forget about PNG8 w/alpha.

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.PoseMotion2011-08-29 20:40:25
B
18
S
5
G
2
Posts: 16
Reputation: 2,012

Post » Mon Aug 29, 2011 8:52 pm

[QUOTE=PoseMotion]Don't forget about PNG8 w/alpha.[/QUOTE]
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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: gomez and 1 guest