I have a question about whether or not this behavior is normal. My game uses a 2048x2048 texture atlas with several dozen items inside of it. Most of the texture itself is transparent (A few large textures and many more small ones). The XML document is 8kb and the texture is 299kb, however my game's memory usage is about 23 MB. Over 90% of that comes from one location: 15 calls to [SPGLTexture initWithData:properties:], which uses about 21.5 MB. Is this normal because of decompression or am I screwing up? Actually I get memory warnings if there are a lot of background apps...and it worries me.
Texture Atlas Memory Consumption
(16 posts) (5 voices)-
A PNG texture is decompressed before sending it to the graphics card, that means it will take up the following memory:
width * height * 4 bytes (for RGBA).
In your case, that's 16.7 Mio Bytes, or 16 MB.
This is what PVR textures are for: they can be sent to the graphics memory in their compressed form, so they take up about the same memory as the PVR file on the disk.
I'm currently working on an extensive blog entry about the topic. It's not finished, but perhaps you can get enough information out of the draft that is available here.
Posted 9 months ago # -
scorpion_hub
MemberThey are ok for animating, I use that format as well.
You get can get compression artifacts if you use the color reduced formats.
Inmy current game I use the uncompressed RGBA8888 or RGB888 format and everything is fine.
Even with the 16Bit color formats, but it seems that you can't produce these
pvr files with Apples commandline tool, so i used the one from GPU manufactor instead.http://www.imgtec.com/PowerVR/insider/powervr-pvrtextool.asp
It's for free but you need to register to download it.
Posted 9 months ago # -
Interesting. I just had my company buy a TexturePacker license because it also exports to PVR GZip in the pro version. I am only having problems with one certain texture at a certain time. Otherwise it worked flawlessly. The artifact almost looks like Z-fighting. There are two jagged objects that come together as one, and when I tween them from side to side the middle flickers a grayish color. This didn't happen with PNG. Worst case scenario I will separate that texture out, otherwise I am very happy. My memory usage dropped to ~4 MB overall.
Posted 9 months ago # -
I think I might know where the glitch is coming from. Those two textures overlap each other (One texture fills the other texture's empty alpha and that is how they slide together nicely) so it might actually be OpenGL Z-fighting when they are moved sideways together....is there any way to combat this?
Posted 9 months ago # -
I can't answer your query borrrden, sorry, and I hope I don't derail your thread..
I'm currently working on an extensive blog entry about the topic. It's not finished, but perhaps you can get enough information out of the draft that is available here.
Perfect timing with this Daniel! I'm still getting my head around instruments but adding up my textures as you have above I think i'm in trouble! I'm really looking forward to the finished article=) I'm not clear on whether the textures inside a PVR atlas need to be POT and square. I'm thinking *not* and that I can just throw the individual png files I have been using into TexturePacker to generate square power-of-two PVR atlases? I'd be grateful if you can clarify this in the final article.
Please continue..
I think I might know where the glitch is coming from. Those two textures overlap each other (One texture fills the other texture's empty alpha and that is how they slide together nicely) so it might actually be OpenGL Z-fighting when they are moved sideways together....is there any way to combat this?
Posted 9 months ago # -
I'll do another test on it, but if I remember correctly, PVR textures have to be not only POT but also square!
Concerning the z-fighting: well, technically, it can't be z-fighting, because the depth buffer is deactivated in Sparrow. But it might be something similar: artifacts of the PVR compression in combination with aliasing effects ... this is all I can think of!
Posted 9 months ago # -
Thanks for trying haha. I know this question has become very specific and low-level. Also, I don't use PVRTC compression. When I do everything looks terrible around the edges, as is common. Somehow or another, TexturePacker makes PVR images with RGBA encoding.
stray dog, I am using PVR textures right now, and only the atlas itself is POT. Actually it isn't square though. I tried making it square and nothing changed. When I turned on PVRTC compression, then the program forced it to square, but with RGBA8888 etc it doesn't need to be square apparently. Aside from the issue above, the other textures are working flawlessly (though I needed to add padding between the shapes inside the atlas the prevent some odd border lines from appearing around the images).
Posted 9 months ago # -
dprijadi
Memberdear daniel
thanks for the new blog link about pvr/png stuff. based on your excellent blog post, is these correct ?
1. to use a PVR texture atlas, i must make a POT and Square texture atlas like 1024x1024 or 2048x2048.
2. While the texture atlas is square and POT, the individual SPImage created from this texture atlas dont have to be POT or Square ?
3. if the size of PVR file is 2mb then thats also the RAM required when i load the texture in sharedMedia class?
4. i can use PNG texture atlas when building program then i can replace the texture atlas with a PVR version for final build ?
5. PVRTX is to be avoided when im using cartoon type images but PVRTC performs well (quality wise) with photo like images ?
regards
dprijadiPosted 9 months ago # -
Thanks borrrden, I did not realize that only the compressed PVR textures need to be square! That's good to know.
Dprijadi,
1) exactly, but (as we just learned) it does only have to be squared if its compressed PVR (PVRTC).
2) exactly.
3) Yes, give or take a few bytes (for the file header).
4) True!
5) Yes, though it's worth trying even in cartoon images; sometimes the results are surprising.Posted 9 months ago # -
You're welcome!
Hehe, you're right, that's why I'm working on that tutorial article!
Posted 9 months ago # -
Also, it is important to make the distinction between PVR textures that use compression in their encoding (PVRTC), and PVR textures that have been compressed (pvr.ccz or pvr.gz). The latter still doesn't need to be POT, and it saves A LOT of disk space (The Gzip compressed PVR for me is just slightly bigger than a PNG file, while uncompressed is about 10 times larger). Unfortunately this annoying problem with the animation is persistent and it looks bad so I'm going to have to take out those textures and make them a separate file.
Posted 9 months ago #
Reply
You must log in to post.