I must be missing something here. It seems that the only compression option I have for iOS is PVRTC, which looks so bad it is not usable. Is this my only compression option? The sprite is not POT but it’s part of an atlas which should bypass that restriction on any compressions that require POT.
People release 2D games that 1) don’t look like crap and 2) don’t take up 200MB+ with uncompressed sprites. So what am I missing?
PNG file compression, would make the uncompressed textures less of an issue in my case but it looks like that’s not happening.
How are you guys making anything other than extremely simple 2D games for iOS?
PVRTC is the compression native to the iPhone/iPad GPU, if something is compressed in PVRTC, it remains compressed even after being loaded into the GPU, so is very fast to transfer and taking up little memory. What most games do is compress as much as they can, but leave certain things uncompressed if the compression artifacts are particularly noticable, like large HUD objects.
Here’s a suggestion for better quality: when looking at the compression options for a texture, go into platform-specific options (the little icons to the right). Choose iOS (looks like a tiny iPhone), check the “override” box, choose PVRTC4, and there is a new option, Quality - you can turn that up to have better quality compression. It defaults to lower quality because better quality takes longer to compile (but the resulting compressed size is the same).
Also, make sure the “maximum texture size” is at least as large as the object - it defaults to 1024x1024, but if you have a texture that is 2048x2048, it will be rendered at half-size before being compressed, which will of course make things worse.
In the other brothers I used 24 bit for opaque and 32 bit for most of the art with some 16 bit for non important elements.
You must have a large amount of art if you’re considering compressed textures.
You can also mix compressed with uncompressed alpha and so on if you want and feel like having slightly heavier shaders.
@Dreamwriter Thanks for the suggestions. I did try PVRTC’s “Best” compression and it’s a littler better than “Normal” but still not good enough. Max texture size is set sufficiently large. I was hoping another hardware-friendly compression like ETC2 would be available, but I guess Unity has only implemented that for Android. I thought maybe a setting (like forcing OpenGL ES 3) would allow ETC2 for iOS.
It’s not up to Unity, the only hardware-supported compression on iOS is PVRTC, unless the new chips that support OpenGL ES 3 added something. Or maybe a different codec could be written in Metal.
I wouldn’t say I have a large amount of art. I’m more concerned about keeping the build size small, not so much the runtime memory footprint. Uncompressed sprites will fill up the 100MB App Store cell download limit pretty quickly, especially uncompressed high-def background images (~6MB each). Other engines handle it by using PNG or JPG compression for storage and then loading it into an uncompressed texture when in use.
I’ve edited my previous post to make it clearer. I’m not worried about the RAM right now. I may have many sprites and backgrounds, but each level only loads a few of them at a time.
Ah I see, well use crunch texture format if its storage space. Use alpha masks separately if you need a higher quality alpha channel. This is minuscule storage requirement and should be close to lossless.
There is also no one size fits all, each texture can use different storage strategies.
I looked through a few of the nicer looking 2D games on there and most of them are above 100MB. And the ones that are below 100MB will download additional assets once the game runs. The Android versions of the games are half the size.
If you’re not already doing so, pre-processing with a bleed can improve the quality of transparent image PVRTC compression. The “Optimize Transparent Areas” section of the PVRTexTool User Manual discusses this in more depth. You can find the doc online here: http://community.imgtec.com/developers/powervr/documentation/
It is the sprite edges that are the worst, so the “bleed” technique mentioned in the PVRTexTool User Manual may help. But I’m using the Unity sprite packer and not sure how to make use of this information in this case.
Ah, I see. One possible solution would be to keep the data uncompressed when you send it to the sprite packer, then use the command-line PVRTexTool to perform a bleed and PVRTC compress the generated atlas. I haven’t got a lot of experience with the Unity editor so I’m not sure what the neatest way to do this would be.
