Using custom spritesheets to boost mobile performance?

Three questions:

• Is there a reasonable way to "hack" a Construct 2 project so that I can use custom spritesheets?
• @Ashley, would you ever consider giving us more options for the creation of sprite sheets within Construct 2?
• Do you think sprite sheet optimization beyond what Construct 2 already does is worth it for mobile?

So here's the deal: Construct 2 currently sacrifices some sprite sheet optimization in the interest of greater compatibility. For example, instead of creating larger more condensed sprite sheets, it creates one sprite sheet for each sprite. To my understanding, it does this primarily to support progress bar feedback. Since there is no way to tell how much of an individual image is downloaded, splitting sprite sheets up allows Construct 2 to count how many of them are loaded from the total, giving a more precise picture of the load progress.

This decision makes sense when considering that Construct 2 was made for HTML-5 games, which are typically "downloaded" rather than "loaded from disk". However, I believe many people are using the engine now primarily for mobile game development (like me). This means the games will be running on less performant GPUs, but will load much faster since they don't have to be downloaded. These lower-end GPUs could benefit from not having to swap textures as often as they would with multiple spritesheets, and the "progress-bar feedback" reasoning here is not as compelling as it is for browser games.

So for mobile-only developers, it would be nice to have the option to pack the sprite sheets manually, with the aid of tools like Texture Packer. Construct 2 games on mobile might consequently see lower memory usage, better GPU performance, and on the whole more native-like experiences.

Now, I do remember reading that Ashley was unable to measure any performance difference between using one giant spritesheet and using multiple ones. However, I don't think the test he used is always an accurate profiler of GPU performance, because the test averages the framerate as reported by the CPU. In my mobile game, despite a reported framerate that's generally 60 or higher, there is persistent stuttering and frame dropping that makes the game look bad. I hope it's just JIT compilation that will be fixed soon, but I've learned to choose skepticism over hope. It seems like there could be something crazy going on with the GPU here that the CPU doesn't seem to capture. That's why I don't completely trust this idea that sprite sheets make no difference. If there is room for optimization that could theoretically help GPU performance, I'd like to experiment with it.

What do you guys think?

Well, even though I think it is not worth the time of scirra, it would still be a nice thing to have just to be sure.

Also spritesheets are sliced also to reduce the size for images where png8 is loseless. Not only for the progress bar, and for supporting devices where textures cannot go over a certain size IIRC.

All 3 question are actual for me right now as I am doing mobile game. I wonder the way Construct 2 does spritesheets cause when I have 1 sprite with 5 frames of same sizes, 36x46, at export i have TWO spritesheets (frames 1 and 2 on 1st, frames 3, 4, 5 on 2nd) instead of ONE. It would be nice to listen what Ashley think about it

I guess you've read the blog post on spritesheets, although some details have changed (it now goes up to 2048x2048 instead of 512x512 for example).

I agree the progress bar argument isn't really that relevant, but there are other significant considerations. It is a surprisingly difficult area with some interesting tradeoffs. One of the tradeoffs is compatibility with existing plugins, which is why currently only Sprite animations are spritesheeted. It's difficult to make changes to C2 at this stage, but I think we will make some improvements in this area for Construct 3.

Here are some other factors that impact how spritesheets work:

• Construct 2 automatically optimises images to PNG-8 when there are under 256 unique colors. The more images on a sprite sheet, the more likely it is to go over 256 colors. Therefore increasing the size of spritesheets can increase the download size.
• The canvas2d renderer does not support rotated source images, which it looks like Texture Packer uses. WebGL can support this, but right now for compatibility with canvas2d images cannot be rotated to improve packing. I want to ultimately drop the canvas2d renderer, but now is too soon.
• When downscaling images a long way, it is necessary to pad images out to power-of-two offsets in the sprite sheet to prevent mipmap bleed (which appears as thin lines appearing along the edges of downscaled images). This reduces the packing efficiency and increases memory use, but is mandatory to completely rule out this type of glitch and is why the "high quality" downscaling option exists. (I don't know if Texture Packer supports power-of-two alignment)
• The performance test I use (an automated version of Space Blaster) is a pretty realistic test I think, and the framerate is the most important performance indicator. It does include GPU throughput, it is not a CPU-only measurement. When experimenting with the different spritesheeting strategies, I literally measured zero performance difference, even on an older mobile device (an iPad 2). I think modern drivers and GPUs are pretty good at swapping textures, and the main optimisation is actually a CPU optimisation so it doesn't have to issue "set texture" instructions, but that is pretty much a micro-optimisation and probably the least of all the concerns here. I do not believe there is any important GPU performance difference using individual images, one gigantic spritesheet, or anything else in-between.

I also have no idea why you would ever want to manually intervene in the layout of the spritesheet. It seems to me almost completely pointless: they will have to be re-layout every time you add, remove or change an image, or even just changing some project properties causes a global spritesheet re-layout (such as changing the downscaling quality to/from "high quality"). If you manually put an image in some position on a spritesheet and then you change something else, the editor has two options:

1) absolutely rigidly for all time insist that the image appears on the sheet where you put it. This is ridiculous, because it will reduce packing efficiency, since after a few edits it may save a lot of space to pack it somewhere else.

2) do the automatic re-layout again and revert your changes. This makes it pointless to have a feature where you can change the layout of the spritesheet.

Neither seems sensible, so I don't think it's worth having as a feature. C2's sprite sheet packer may not be perfect, but I think it's at least OK, it does the job of saving memory, and it does it automatically so you don't need to worry about it.

Ashley thank you for answer. I really enjoy using Construct 2 - it's awesome and easy to handle. But while doing HTML 5 game for PC is one thing where you shouldn't worry about such things, mobile game is another one - every step should be as efficient as It could be, as I see it. I am using Construct 2 for about two month, also am not a programmer, more level- and game designer but even I can do a GAME with Construct 2. I hope Construct 3 would be the best game creation tool ever