RAM issue seems to be caused by tk2dSprite and tk2dAnimatedSprite

[Lightja]

Hi, I'm making a 2d platformer game in Unity that we are porting to Android and apple devices.

the game's prototype was built by one designer, and now the project has been picked up by a 25+ person team. We changed all of the code to c# from JS and made everything time-dependent and just generally fixed up the project.

One major issue that remains is the RAM usage. When I deploy the game to my phone, in our basic scene, which includes 3 floor objects, a camera prefab that includes all of our GUI, and our player and his sprite which is animated with movement, etc. This scene is taking 244mb of RAM on my LG Optimus f3. This is too much for a phone game, correct?

When trying to isolate the RAM issue I tried deleting pieces of the scene and rebuilding it. I can post my trials, but they don't seem to make much sense to me. Generally speaking, when I delete the camera, 150mb of RAM is freed up, so it goes down to about 100mb of RAM being used, and when I delete the character, I free up about 50mb, leaving ~40mb in the completely empty scene.

I attached a txt file that entails the results of me deleting objects piece by piece. All of the objects that were deleted that resulted in a big drop (touchCircle, lifeOutline, and coleSprite) used either tk2dSprite Script or tk2dAnimatedSprite Script.

touchCircle and lifeOutline both use the same Atlas, and it is a 4096x4096 atlas. We plan on reducing it to multiple 2048 atlases for the sake of the maximum atlas size on apple devices, but that is just a matter of time. Could the size of the atlas be a memory issue?

the touchCircle, lifeOutline, and coleSprite when deleted in my trial that went piece by piece caused the biggest drops in RAM, but when I deleted those 3 only from the basicScene, there was only a drop of only about 50mb, which I suspect was just from deleting coleSprite, which is our character.

Any advice on where to continue from here in trying to reduce the memory consumption of our game before it continues to get worse? Our first real scene takes about 300mb to run, and it just keeps increasing.

Thanks,

-Justin

[BTS]

touchCircle and lifeOutline both use the same Atlas, and it is a 4096x4096 atlas. We plan on reducing it to multiple 2048 atlases for the sake of the maximum atlas size on apple devices, but that is just a matter of time. Could the size of the atlas be a memory issue?

-Justin

This, my friend! The bigger the Atlas-Size the bigger the RAM consumption. If you look into the Atlas-Data in the Unity-Inspector you will see how much of RAM the Atlas will consume when loaded.

So here is my advice:

- make them smaller. Not only the Size but also Format (which has also a big impact on the RAM-Size)

For example, I have one TextureAtlas for my Sky-Background which is a PSD-File/Sprite with a Gradient. It's 2kb in RAM-Usage (Max Size is set to 64 and Format is set to "RGB Compressed PVRTC 4bits"). Of course I could set it to 4096 and RGBA 32, but that would be just dumb, because there is absolutely NO difference in quality, at least you can't see it with your eyes

In order to save fillrate unikron told me to split up sprites in two parts: one part with transparencie the other one is solid. Now this will save you also a lot of memory, cause your solid-part has (in best case) only on colour. My Solid-Part-Textureatlas is set to 512 in Size and the same RGB Compression in the Format Setting and gives me a RAM-Usage of 128 kb.

With GUI, Character, Enemies, Backgrounds etc. I got something like 80-90 MB of RAM Usage, that being said, only the Background-Atlases are optimized, so I think I'll go down to 60-70 after optimizing the Atlases of the Player, the Enemies etc.

[unikronsoftware]

An uncompressed 4096x4096 atlas will occupy 64MB of memory at the very minimum. You will need to compress the textures if you wish to have such large amounts of textures in memory.

Deleting them should reduce the memory usage, but perhaps something remains loaded for some reason? References to prefabs, perhaps?