How to reduce project exe and data size?

[shaz68]

I am porting a game to Unity that was originally made with TGB. 

In TGB every image was a separate png file, and levels were built via code rather than saved as scenes containing the images.  The resulting exe is 1.5MB and the entire game folder is 22MB.

In Unity, I've imported all the assets into the project folder and put all of the sprites into sprite collections (I took mostly the default settings, other than changing the anchor point and collision box).  Most of the sprite collections generated a 1024x1024 or 1024x2048 sheet.  When I build the game (again using the default build options), the exe is 8.1MB and the entire game folder is 85.9MB.

This is a HUGE difference, and there is a LOT still to be added to the Unity version (animations, audio, lots more code).  Just the sharedassets files combined are twice the size of the entire TGB game.  I don't know where to begin looking to get the size of the exe and project down.  Is this big difference something that's standard with Unity, or peculiar to the 2d toolkit?  Can I load the sprite collections and animations at runtime, or does Unity already do that?  Any ideas what things I can change to reduce these numbers?

[unikronsoftware]

Hi shaz,

You can't do anything about the exe size (8.1MB) as that is the Unity runtime exe. You can possibly do a few things to reduce the size of your assets, but I'll explain why it is the way it is first.

When you use png images, it has to get decompressed (possible recompressed using DXT, etc) and uploaded to the VRAM. What the Unity asset pipeline does is, when you import a png, it decompresses it and recompresses it using the compression format you tell it to. It can also be uncompressed (32 bit or 16 bit RGBA) This means that there isn't any intermediate step which needs to be performed when loading to the GPU, and everything is really fast and nice. Sometimes this works out better than png compression, but most of the time it does not. You can obviously improve file size (at the cost of image quality) by changing the compression settings but you'd have to do this on a case by case basis - sometimes DXT compression artefacts are acceptable and sometimes they aren't.

You can see the file sizes of individual assets in your project (and what ends up taking up the most space), by looking at the Editor Log after building your player. You can get to this by clicking on "Open Editor Log" in the console window. One thing you want to make sure is that none of your source textures are being included.

unikron

[shaz68]

Thanks for the explanation.

According to the docs, as long as I'm only using my original sprites in sprite collections and not in any scenes, they will not be included in the build.  But I'll check the log and see if that's happening.

Is it usual that the sprite collection takes up more space than the original sprites?  With the extra unused area on the texture (most of mine are about 43% unused), plus whatever files are necessary to create the atlas and animation, I imagine that's a possibility.

[unikronsoftware]

If the atlas has empty space, it will be full of black pixels with 0 alpha and in this case, it would be compressed quite well and wouldn't take so much memory on disk, however vram would be wasted as it would be uncompressed with the blank space in there.

The atlas can easily take up more memory than the total of the source png sizes, for the reasons I explained before. However, it shouldn't be significantly larger than the each texture size in Unity totalled up. (click on each texture, and the size is shown in the Preview window.

[shaz68]

Well, the editor log shows that none of the original textures are being included in the build.  However, if I choose a sprite collection that has only 3 sprites, the total size of the individual sprites is 7MB.  The atlas texture in the sprite collection is 21.3MB.

The atlas is uncompressed ... I already see a loss of quality with the images in Unity compared with the original sprite - I'm not sure why - and I don't want any further deterioration with quality.

[unikronsoftware]

What are the dimensions of the atlas and the source textures?

[shaz68]

For that particular file, the atlas is 2048x2048, made up of 3 textures which are 1024x768, 1024x768 and 640x480.

Another file with just a few images is 1024x2048 (10.7MB) for the atlas, made up of 1024x768, 129x300 and 870x325 (total 4.2MB).

I notice my source sprites all have NPOT next to them.  What does that mean?  I got them into the project just by dragging them from an external folder onto the project panel.

Attached are my sprite collection settings, in case it helps.

[unikronsoftware]

Yeah, that atlas is less than 50% used, there will be loads of wastage there. This won't really translate to a much bigger final file though, as the textures will be zlibed up and empty space zlibs up incredibly well. Having said that its not really good practice, as the texture will be 50% empty in memory when it gets loaded up.

NPOT = non power of two. Unity, by default, will upscale every texture to power of two dimensions, so 1024x768 -> 1024x1024, and so on. Thats really bad when you want pixel perfection.

[shaz68]

okay ... if the atlas is less than 50% used, why didn't it size it to 1024x2048?  All others ended up around those dimensions.  Maybe slicing the image would let it do that, but I haven't seen an option to slice in the sprite collection - only to add a sliced sprite as an object.  Can you tell me how to tell the sprite collection to slice them?

This NPOT ... if Unity upscales, is that going to cause the graphics to be blurry?  This is a problem I've had, and not been able to figure out why.  But they don't seem to be distorted in any way, which is what I'd expect if that were happening - there would be stretching in one direction, wouldn't there?  Is the solution to make sure the source image is a power of 2 before putting it into the sprite collection?  So I could just add transparent edges?  That approach wouldn't work, though, for spritesheets.  What would you suggest as the solution?  The sprites are all from an existing game in another engine.

[unikronsoftware]

The atlas can in theory by < 50% used and still occupy a bigger texture, depending on the orientation of them and how it gets it to fit.

You can enable dicing on the textures to help here, but this will not work if the sprites end up being animated. This is an option per sprite.

The NPOT texture issue shouldn't affect you if you are using a SpriteCollection. You don't have to do any additional work for this, the toolkit takes care of it automatically. If you are still having issues with it being blurry, I'll be able to work it out for you if you can send a repro case.

[shaz68]

Thanks for all the info.  I'm still not closer to getting those atlas sizes down though, so I'll have to keep looking at it.

How do I enable dicing on the textures?  Is it something I do when creating the sprite collection (since it changes the way the sprite is saved in the atlas)?

[unikronsoftware]

Simply edit the sprite collection (select it, and click on "Edit") then enable dicing on the sprite you're interested in and select an appropriate X and Y size for the dicing.

[shaz68]

Thanks!  I didn't even think to look in the Edit settings.