How to disable the spritesheet system used by Construct 3?

Hi, I'd like to disable the spritesheet system used by Construct 3 and return to the C2 system.

The reason why I need to do this is that I need to apply a lot of lossy compression on my images so that the game can be reduced to less than 100Mb in order to be uploaded on Google Play. If I do that on the shared spritesheet, the quality is unacceptable (too many different colors on the same file for the compression to look correct).

Also, the game exported with C3 crashes sometimes, while this never happened with the C2 export. Unless I'm missing something, this is probably due to the different object used on the same spritesheets, which may saturate memory.

For these two reasons, I'd like to revert to the C2 spritesheet system. If another way of dealing with the problems I have exist, I'm interested in learning about it.

Thanks!

Are you compressing images using some external software, or this option?

Splitting spritesheets in to individual images will actually increase the download size.

Suppose you have 20 frames of the player sprite, and the player's head is the same in every frame. A spritesheet image will compress away to nothing the 19 copies of the identical player's head as identical to the first, making the file smaller. If they are in separate images, then each file must store a full copy of the player's head - even if compressed, you'll have 20 copies of the same thing.

In other words, when all the images are in the same file, image compression can remove similar parts of the image across frames. So you're hoping that tweaking the image compression format will more than outweigh the effect of bloating the download size by splitting everything in to individual images. It's not clear that this will be effective.

So if I'm correct the RAM usage is MUCH higher than if every object type had its own spritesheet, as in C2. This is probably why the game is crashing all the time when exported with C3.

You can customise the spritesheet size to help manage the tradeoff here. Do you have actual measurements to indicate the difference?

FYI automatically generating spritesheets are extraordinarily complicated and have many subtle tradeoffs. I have worked on this extensively for years and there are a lot of surprising results. It depends entirely on the project and specific images being used. Spritesheeting can actually reduce memory usage thanks to power-of-two packing, can reduce the download size, improves runtime performance, and usually significantly improves loading times. However it comes at the cost of reducing texture memory management granularity. C3 does arrange images together based on their usage across layouts to try to mitigate this.

I don’t have measurment other than my game passing from not crashing to crashing. :)

C2 and C3 provide measurements specifically for this. I was suggesting that you look at them.

I didn’t mention it earlier, but another big problem I have using C3 instead of C2 is the huge performance drop... My theory about this is the following: Healer’s Quest sometimes needs to load very small images that are not present on the layout in the editor (they are too situational and there are too many of them to load them all on all layouts).

This forces a synchronous texture load and can easily cause jank in the C2 runtime. The C3 runtime actually loads textures asynchronously which should solve this problem (at the expense of possibly a couple of frames where the texture is invisible because it hasn't loaded yet - but avoiding the jank). As has always been the case, for best performance you must have every object that can be created in the layout initially placed in that layout, and destroyed on start of layout if need be; this means Construct will pre-load everything the layout uses and completely avoid any on-the-spot texture loads, which can hit performance no matter the size of image being loaded.

Then in C3 this becomes even more important, because it analyses the objects initially placed on layouts to identify the objects that are most commonly used together, and then groups them on the same spritesheet. This can lower memory usage by making sure the images on a spritesheet are always used at the same time, helping eliminate the case where you load a big spritesheet with lots of images that aren't used.

So this is a known case and has known workarounds. The jank from on-the-spot texture loads should be pretty much fixed in the C3 runtime thanks to its asynchronous loads, but even in the C2 runtime, if you do all of this it will make the performance even better than it was to begin with, since it won't even need to to on-the-spot texture loads even for small images.

Thanks again for the reply. I'll keep all this in mind for my next project. For this one however, I'll stick to C2, because while there is a workaround, it'll take a lot of time (days or weeks) to drop hundreds of different objects on hundreds of different layouts and rethink everything, and I'm still afraid there could be RAM issues in the end.

So if anyone has a solution to hide the status bar on iPhone 7 & 8 for a project exported with C2+C3 export manager, I created a thread here.

And for the bug of the black background which can't be set to white on iPhone X, I created a thread here.

Thanks!