SpriteSheets are wasteful

Discussion and feedback on Construct 2

Post » Wed May 14, 2014 3:28 pm

Is it in the road map to have Construct 2 optimize spritesheets? Spritesheets created by Construct 2 are incredibly inefficient. Other engines and tools pack spritesheets by trimming empty space around images and internally keeping note of how much got trimmed to properly maintain offsets. They also try 90 degree rotations on images to optimize space in the spritesheet. The effect is spritesheets that are much smaller. That makes the app size smaller and improves performance because the draw fill rate is also reduced.

Another inefficient area is with duplicated frames in animations. Currently if you duplicate a frame it actually adds a copy of that same frame to the spritesheet. The engine should be smart enough to avoid this.

These two optimizations would reduce the file size, download size and improve draw performance significantly. I sure hope Scirra is working on implementing this. This is standard with all 2D engines and severely limits the size of a game's content without it.
B
5
S
1
Posts: 24
Reputation: 423

Post » Wed May 14, 2014 4:53 pm

If you look through the past release notes you will note that it does deduplication on duplicate frames on export. These optimizations only happen on export, not on preview or on save.

Also, try using something like spriter so you can get away from having to worry about having frames at all.
B
49
S
12
G
10
Posts: 1,833
Reputation: 14,603

Post » Wed May 14, 2014 4:57 pm

I second @Kronar
B
8
S
2
Posts: 163
Reputation: 1,115

Post » Wed May 14, 2014 5:02 pm

Kronar wrote:Is it in the road map to have Construct 2 optimize spritesheets? Spritesheets created by Construct 2 are incredibly inefficient. Other engines and tools pack spritesheets by trimming empty space around images and internally keeping note of how much got trimmed to properly maintain offsets. They also try 90 degree rotations on images to optimize space in the spritesheet. The effect is spritesheets that are much smaller. That makes the app size smaller and improves performance because the draw fill rate is also reduced.

Another inefficient area is with duplicated frames in animations. Currently if you duplicate a frame it actually adds a copy of that same frame to the spritesheet. The engine should be smart enough to avoid this.

These two optimizations would reduce the file size, download size and improve draw performance significantly. I sure hope Scirra is working on implementing this. This is standard with all 2D engines and severely limits the size of a game's content without it.



Can we see an exemple where it is really wasteful? (aka an actual exported file on one side and how it could pack it better in your opinion )
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Post » Wed May 14, 2014 5:16 pm

Thanks for your reply.

I am using r168 and duplication of duplicate frames definitely occurs on export. Please do tell if you know of a setting or configuration somewhere that I am unaware of.

In my case Spriter has no place as I am using prerendered 3D isometric animations. But that is irrelevant because the same inefficiencies I mentioned earlier affect Spriter. Unless Spriter completely bypasses Constructs spritesheets and creates its own packed spritesheets that are used by Construct. Is that the case?

In any case, optimized packed SpriteSheets is something Construct 2 is in desperate need of. I am very surprised it has gone this far without them. Imagine without any additional work, changes or any external plugins making your game much smaller and faster.
Last edited by Kronar on Wed May 14, 2014 7:31 pm, edited 1 time in total.
B
5
S
1
Posts: 24
Reputation: 423

Post » Wed May 14, 2014 5:46 pm

@Aphrodite,

I don't have the time to create an example right now, but you can learn what a sprite packer does by simply googling it. This is all common stuff that has been used for many years. Here is a link to a third party sprite packer application: http://www.codeandweb.com/texturepacker

In that website you will learn the difference between a non packed spritesheet and one that has been packed. This may be a good way to add this important feature to Construct 2. Instead of having the Construct 2 team implement it, they can help third party developers add Construct 2 file support. You'll notice how that tool alone supports over 15 2D game engines, again this is all common stuff, everyone does it.
B
5
S
1
Posts: 24
Reputation: 423

Post » Wed May 14, 2014 6:38 pm

What you could do is a comparison of the compressed spritesheet C2 puts out with the one you get from texturepacker.
If the differences aren't negligible, then he would be more likely to implement it, how ever I can tell you if it means a dependency on a third party that's not open source then he probably wont even consider it.
Image ImageImage
B
171
S
50
G
180
Posts: 8,396
Reputation: 113,986

Post » Wed May 14, 2014 7:20 pm

Data 'compression' used by graphic file formats such as PNG or JPEG, has nothing to do with any of the issues I mentioned. Data compression only saves on file footprint. Using something like TexturePacker(I have no affiliation with them) is not a third party dependency because it is completely optional. Only people wanting to optimize their game would employ this technique. Not using it (as you do now) would not prevent you from creating and publishing a game. Its a good idea to use third part tools that are not required dependencies. This is completely normal, all game studios use many tools in their development.

I went ahead and created a spritesheet with TexturePacker to compare against my current sheets from Construct 2. You'll notice in the TexurePacker output there are no duplicate frames, which is one of the optimizations I mentioned. The following spritesheets were constructed using the exact same graphics which consist of 28 unique frames. Construct 2 unfortunately duplicates frames in animations making the spritesheets even larger than they need to be.

Construct 2 creates two spritesheets, each 1024x1024 in size. This takes up a total of 8MB in memory. 616KB combined file footprint size. Construct 2 does this because it doesn't know how to 'pack' it efficiently into one. Notice how wasteful the spritesheets are with lots of empty space between the sprites. That empty space between the sprites is the real killer.

TexturePacker for the exact same graphics creates one spritesheet that is 512x512. This takes up a total of 1MB of memory. 350KB file footprint size.

As you can see, packing spritesheets uses much less memory, has a smaller file footprint and speeds your game up because the GPU uses less fill rate to render these sprites.

Image
Image
Image
B
5
S
1
Posts: 24
Reputation: 423

Post » Wed May 14, 2014 7:42 pm

Sure is a lot of white space in the first image.
Those were not cropped before import?
As to the duplicates, I think that depends on how the texture is added.
Also, not sure if he can even do rotations. Surely it can for webgl, no idea for canvas2d.
Image ImageImage
B
171
S
50
G
180
Posts: 8,396
Reputation: 113,986

Post » Wed May 14, 2014 7:47 pm

I see now, I guess C2 wasn't optimised towards that point because it will only spritesheet frames from the same sprite, so I think they didn't consider that to be an issue (since the frames would be most likely similar, it maybe wasn't obvious to see it), Also the frames needs to be cropped in C2 too, so it can interpret them correctly at the end still. However I still see the point, and it could be nice in the long run.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Next

Return to Construct 2 General

Who is online

Users browsing this forum: tarek2, Yahoo [Bot] and 11 guests