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?

  • My game started crashing on some iPhones after adding more players. Turned out it was due to RAM usage. As soon as I reduced that it worked again, so everything points to that.

    having said that there are some possible issues here:

    On a couple of my attempts, using Construct 3 to export this game ( game itself is 100% Construct 2 )

    it started crashing even on other phones, again because Construct 3's Spritesheets use more RAM.

    As for game/download size:

    I did use PNGoo to recompress images after export, because recompressing in Construct 3 did very little.

    With my method the final game was around 13 MB, using only Construct 2 or 3 compression it is at least double that size.

    So, having spriteshhet option to revert to Construct 2 way, seems like would definitely help in situations like this ( with RAM issues ), but unless I am missing something using externaal software to reduce download size still seems to be the only 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.

  • Thanks for all the replies.

    I didn't change the image compression format inside C3, I use tinyPNG to recompress everything.

    Ashley , here is an image from the exported image folder in C3. It contains images from roughly 15 or 20 different objects in the game. That means in every layout where any of these object appears, the whole 1024x1024 image is loaded in memory... In addition to many others.

    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.

    The secondary (less problematic, but still) problem, is that with so many different colors on one image, tinyPNG's compression gets very crappy.

  • 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.

  • 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.

    From my recent experience I would say yes, that is exactly why it's crashing.

    I was lucky enough that some basic cleaning up/cropping of all images did the trick and reduced RAM usage enough so that Construct 2 export now works, as I was already in the process of trying to figure out how to split things over 2 layouts and halve RAM usage, and that would have been somewhere between pain in the ass to impossible.

    I don't know what your case is, maybe it is possible to split things over 2 layouts. Can't think of any other options.

    You know, move half of the stuff to another layout, and do the old school, fade when entering a door or a cave and switch to that layout, same when you go back. But without knowing what your game is I am kind of just guessing.

    That would solve the RAM issue, but not the total download issue you have.

  • Thanks for your reply

    Ashley

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

    I would be glad to send you the project file if it could help, but last time I send it you told me that there were too many third party addons required. Which is also part of why it took me so long to update to C3 and I’m still unable to use C3 runtime.

    I have no doubt that in most situations C3’s spritesheet system is much better than C2’s, and you sure did an amazing job with it. Just in this situation it doesn’t seem optimal. Thanks for the info about the way it’s working. I use a “container” layout which regroups most sprites from the game on a single layout (even though some of them are also dispatched amongst other layouts for loading reasons), from what you say I understand this could be a big part of the problem.

    Biggest problem: performance drop

    I didn’t mention it earlier, but another big problem I have using C3 instead of C2 is the huge performance drop. It runs very poorly on the C3 exported version while C2 was completely fluid (50-60 fps at all times on a mobile phone). To be more precise, there are sometimes freezes of 0.5 up to 1 second in the middle of the gameplay.

    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). With C3’s spritesheet system, these very small objects may be part of a big unloaded 1024x1024 pixel spritesheet (if not dispatched amongst 3 different 1024x1024 pixels spritesheets), and the game freezes while the spritesheet is loaded. I already put the maximum spritesheet size to 1024x1024 and it didn't help.

    To be complete, I should say that these big freezes not only happen on my phone, but also on my computer when previewing the game, which never happened with C2.

    I even recorded a video of the freezes happening on my computer, here is a link to it:

    youtube.com/watch

    I think at least two of the 3 freezes in the video happened due to the loading of a new object.

    From all this, I conclude that my game has been developed with C2 in mind, and it just doesn’t suit the way C3 works. Don’t get me wrong, I already use C3 for my next project, and it’s much, MUCH better than C2! I’m just saying that Healer’s Quest works better as a C2 game unless I take weeks to completely rework the code...

    To reply to BadMario , Healer’s Quest is already split into something like 300 layouts, but the container layout is probably a big part of the problem.

  • 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.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)