Brian - July 5th, 2010 - One Step Back, 1.5 Steps Forward
PVRTC for the iPhone/iPad sucks, but it's a necessary evil.
PVRTC is a texture compression format. It's a fixed-ratio block compression format meant to be decompressed by graphics hardware, hence allowing you to store more texture data in the limited texture memory available on the hardware. PVRTC also has the distinction of being the only compressed texture format available on the iPhone & iPad.
So then why does it suck? Two reason:
(1) PVRTC is not good with gradients or sharp edges. Uhhhhh. OK. This may leave you with the question, "Well, what is it good with?" And I present to you my answer: "I don't know." Depending on what compression tool you use, PVRTC compressed images can be OK or they can be unbearably bad. I find the official Power VR tool for Windows to be reasonably good and not too slow.
(2) PVRTC only supports square power-of-two (pot) sized textures. This is the big one. The pot texture restriction has been common-place for some time now. The square restriction, however, is a bit of a problem.
Allow me to expand on #2. The problem comes when you're dealing with a sprite based game. Sprite based games tend to have various sprite sheets that contain all the animations for the sprite - or alternatively (and badly) each frame of animation is its own image. In either case, you very rarely have images that fit neatly into a square pot-sized image.
You have a couple of options here:
(a) You can pad the images to the nearest available size.
(b) You can break apart your sprite sheets so that they're close to available sizes, and then pad those.
(c) You can devise a clever scheme for packing images together to get the packed images close to an available size and then... pad those.
(d) You can resize your images to make them larger/smaller. And then pad as necessary.
Unfortunately, pretty much all of these solutions have accompanying problems.
(a) You're likely to end up with some pretty big images and a pretty huge waste of space. If your sprite sheet is, say, 512x1024, it now becomes 1024x1024. It doubles in size.
(b) Breaking apart sprite images can be pretty time consuming. Especially if you're doing it after-the-fact; by the time you actually run into a memory problem, you've created a lot of work for yourself.
(c) In all likelihood, you'll be loading more in a section than you need to. If you pack two images together and you find that you only need one during the level, you don't have the option of only loading the one. Plus this has the same problems as (b) - it can be a lot of work.
(d) No artist wants to see his carefully crafted image scaled unnecessarily, losing detail. And in this case you're either losing detail or using more memory, none of which you want.
If we ignore added workload, most of these drawbacks come back to the same bit of text that repeated itself while I presented the options - "pad the images." Whatever you choose, you're likely going to be padding images significantly - making them powers of two may not be a huge deal, but making them square will likely be painful. You're looking at doubling a given dimension for a lot of images. Ew.
How bad is this really? Well, obviously when you're fighting for every bit of memory, it's very far from the ideal. It may, however, not be a deal breaker. It turns out that in terms of FILE SIZE, padding a PNG and then compressing it using PVRTC can do anything from make it slightly smaller to slightly larger (depending on the amount of padding, of course). Taking a 512x1024 PNG, padding it to 1024x1024 (ew ew ew), and then running it through the Power VR compression tool will usually generate a larger image; I don't remember numbers off-hand, but I think it was about 300KB - 500KB larger.
In terms of MEMORY USAGE, though, you're likely to still get a big win. PNG gets completely decompressed before going to hardware. I took a 2MB PNG and decompressed it in GIMP to export an 8MB raw image. PVRTC does not get decompressed in the same fashion, so if you have a 2MB PVR image, the hardware is receiving 2MB. Of course, that win is bigger when you don't have to add a huge empty buffer onto your images, but it's clearly much better than nothing.
I do look forward to the days when Apple drops the square size restriction.
Did I inadvertently sign up for a Becca-themed newsletter?
