I’m having problems RAM on my iPhone. Using the Xcode memory profiler, I’m seeing my app run through the memory roof for no apparent reason.
My game is texture heavy, and I start out with menu screens using non-square, uncompressed 32-bit RGBAs. Mem usage there is around 15MB. But when I go to load the main game, Mem usage jumps to 50MB+ and my game crashes half the time, especially if debugging through Xcode. But the thing is, my scene doesn’t have 50MB of textures in it, the whole game should be under 50. Nowhere near that much. I’m showing about 18-20MB of textures using the in-editor statistics panel.
The only way I could be using that much memory is if my initial menu screens aren’t being cleared from RAM on new Level Load. Can someone please confirm that Unity is supposed to release textures from an old scene? What’s going on here?
BTW, I’m not loading these textures through Resources.Load. I’m simply using prefabs, or, in the case of menus, several GUISkins.
Also, I’m wondering if having many separate GUIskins is a performance problem. I have about 6 of them for organizational reasons. Is that okay?
================== EDIT ===================
Looking at the profiler now, it seems that just at my custom Splash screen – which immediately follows Unity’s, my app is already at ~45MB. How is that possible?
PVRTC reduces memory consumption by 75%. With RGB you lose that compression + if your textures are non-square you’ll also be adding unnecessary memory load.
I’d love to use PVRTC, but their quality is completely unacceptable. I’m doing a lot of testing to find out what the problem is. Looks like non-power of 2 and non-square is a total iPhone game killer. It’s not simply that you need power of two to enable compression. Non-power of two even uncompressed still eats double the RAM than if you made it square.
I just stripped my game of the front menu screens (a lot of small non-power of 2 textures), and I got the RAM usage down from ~45MB to about ~15MB. That’s insane. Those textures weren’t even in the same scene as the gameplay.
Bottom line: DO NOT USE ONGUI EVER! ALL GUI MUST BE DONE IN 3D.
Plus, ONGUI seems to leak like crazy.
I just spent 2 weeks building a complex menu system. Now I have to scrap the whole thing to redo it using Sprite Manager 2 or EZGUI. Wish this problem was documented somewhere. All I keep hearing about is how GUI is bad for draw calls, so I made sure to keep things under 25 calls and FPS was great. But even if you make it past the draw call hurdle, you run up against the RAM brick wall.
I did minimize use ON THE SCREEN, but that wasn’t my problem, and I wasn’t using GUILayout at all. It should say, “minimize use of GUI OFF SCREEN” as well, cause every one of those innocent-looking 50x100 pixel buttons eats up tons and tons of RAM that should be used for your game.
Turning off mipmapping on the texture will decrease memory usage, as well as lowering “Max texture size” to the closest possible dimensions of your texture. For example a 32 x 32 pixel texture shouldnt be imported with 1024X1024 setting in your import options, or it’s a huge waste of memory. also dont use the compression setting instead manually change to RGB compressed DXT1 if its not using a transparency, and it is use RGBA DXT5. This will save ram, and save you from the horrible compression artifacts of the auto compression.
Yup, all those points were observed and it’s still not good enough. Not by a long shot.
Unity loaded about 10-20MB of GUI textures for my menus and never released them, EVER! Even if I load the next scene, which then crashes as a result. Tons of leaks too, so I strongly advise to avoid GUI for iPhone if you have more than a couple of buttons.
GUITextures are fine, if you mean avoid using GUILayout based objects then you are right. But that is well known and in the manual as pointed out to you.
I think you need to embrace the theory of testing on the device early and often. It’s pretty much a staple of any mobile development. It seems like you got a long way into your project before realising these issues.
That’s incorrect. The max texture size is just that: maximum texture size. It certainly doesn’t expand a 32x32 texture to 1024x1024; that would be absurd. All it does is limit a texture so that it can’t be bigger than 1024 in either dimension (if it is, it’s scaled down to fit).
Also completely wrong. Auto compression merely picks a compression type for you; it doesn’t do anything else at all. In regular Unity, there is only DXT1 and DXT5, no other compression types. In Unity iPhone, there is PVRTC2 and 4. The only reason not to use auto compression is if you don’t actually want compression, or if want to override the choice it made (say if it picked DXT5 but you only need DXT1).
I have a habit that whenever i’ve got a mental block from javascript, I’ll skim through all the assets and check that every asset is being trimmed as small as humanly possible.
