SpriteSheets are wasteful

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.

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.

I second Kronar

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 )

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.

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.

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.

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.

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.

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.

The images were purposely not cropped because aligning different sized images to have the exact same origin would be incredibly difficult and nearly impossible to maintain (in case you change any image). Even cropped versions would still be incredibly wasteful.

Cropping is always handled by a utility or the engine itself. For instance in Unity 3D, all cropping, packing and rotating is done automatically for your 2D games. Even third party libraries such as TK2D do all of this. With other engines like Corona, Moai, Marmalade or cocos2d etc..., it is done externally with an application like the one I mentioned. You don't ever want to do this by hand, not only would it take many hours for a single spritesheet but it would be prone to being inaccurate.

Regarding your comment on duplicates. Please do tell the secret on how to add frames and avoid duplicates in spritesheets. Construct 2 should easily be able to tell duplicate images and not repeat them wastefully in spritesheets. This is a bug.

90 degree rotations are trivial and at the GPU(webgl) and software levels(canvas2d) have no performance penalty.

Even if it was pre-cropped to the nearest pixel it might still have all the white space if those objects can't be placed to the nearest power of 2.

That would probably be solved, at least in this case by rotations.

As to the duplicates, I always assumed it was based on the object, if not to all the objects animations, as it should assumed there would be no duplicate textures on other objects, relying a bit too much on some planning on the users part perhaps.

Anyway we have to belay casting blame as there's only one person doing the development, and his todo list, even though it is legendary, is not public, and while those changes aren't exactly trivial, aren't basically basic.

Kronar

I agree that this should be implemented, but for the most games made with C2 it wouldn't increase the performance too much.

One alternative solution to your problem is Spriter.

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.

Yes, there are a lot of white space but judging to different result from Texture packer, the angles are different.

newt Where was blame cast?

tgeorgemihai Spriter is an entirely different tool for an entirely different purpose. Please read the entire thread to get a better understanding.

Joannesalfa 90 degree rotations are standard optimizations when packing spritesheets. Think 'Tetris', where you rotate the shapes to make them fit tighter together.

I took the time to thoroughly explain the problem so that the community and project would benefit. I want Construct 2 to continue to improve, I thinks its a great application. It already supports independent origins with each sprite frame so supporting a third a party application would be pretty easy to implement. This definitely takes priority over less useful new features like Spriter as using a spritesheet is a requirement not an option. Every single Construct 2 user would benefit greatly form this, even Spriter users would benefit.

Let me reiterate by saying that If spritesheets were properly packed, the benefits would be HUGE. This isn't a small gain, or a good gain, this is a HUGE gain. It would not be uncommon to see a large reduction in file size, very large memory requirement reduction and FPS boost. All this without lifting a finger. All Construct 2 games would instantly gain that, no additional work, all done automatically for you.