I finally got my iPad (WOOOOHOOOO) and installed the 5 apps I’ve been working on. All work fine but one, which crashes the iPad on launch. It works in Unity and in the iPad Simulator.
I see that it generated some “low memory” crash logs, so I guess that’s the problem. But what does that mean? This app does include a larger-than-normal number of 2D textures, as it displays some photos. But there’s never more than one being displayed at a time (in addition to a few GUI elements). I have a placeholder texture on screen and use SetPixels to copy to it. Is there a limit to how many textures I can include in a project, or how big they are? Does it matter how they are compressed? Any suggestions?
low memory means that you use more RAM than the device so it gets killed.
using setpixels is a very bad idea as that means that a RAM dublicate of textures is required (so they need twice the amount of ram, once in RAM, once in VRAM).
also there is no compression for images post loading unless they were PVRTC compressed at start in which case get and set pixel(s) are not available.
all other textures are pure bmp data in ram and vram
Make sure all textures or images used are square, eg. 1024 x 1024, then resize them using code… (multiply the height of the image by 0.75 to get it to fit the ipad screen)
In some cases I need to use SetPixels as I’m generating textures on the fly. But I just have the one texture I draw on over and over, so I don’t think that’s the main problem. It’s the photos that must be the culprit. I’ll need to figure out a more efficient way to deal with those. But I’m still not sure why this is a RAM problem. Does everything get loaded all at once? Even though there are lots of images in the project, there’s never more than one displayed at a time. It would have been nice if Unity or the Simulator would have given me a warning so I didn’t go so far down the wrong path before finding out.
no not all is loaded, only the stuff thats referenced in the scene (independent if seen or not. when they are seen they are additionally uploaded to the vram if get/set pixel is active or the texture was created dynamically. otherwise the texture leaves ram and ends exclusively on vram)