Hi!
I have a PNG file which is 1042x1024. I am using the RGBA4444 pixel format.
If I load this image it should consume 1024x1024x2 bytes of texture memory, in theory.
I converted this file to a PVR which is now 528KB on disk and 1024x1024 in size.
It is also using 4 bits per pixel.
I read somewhere that PVR files do not get uncompressed because the hardware inside the iPhone/iPad handles the data directly.
Does this mean that when I load my new PVR file, and display it, it is only using 528KB of texture memory?
If not, then is there rough calculation that can be used to approximate the amout of texture memory my new PVR file is going to use once loaded?
Thank you!
PVR Textures and Memory
(31 posts) (9 voices)-
MasterP
MemberPosted 1 year ago # -
@Ricardo1980 I don't know what you mean.
MasterP asked how much memory an image will use in a given compression and dimension, and Karl answered correctly.
You can exactly know (not roughly estimate) the amount of texture memory used by applying the following formula:
memoryBytes = width * height * bitsPerPixel/8; //Converting to different units is simple: memoryKBytes = memoryBytes/1024; memoryMBytes = memoryKBytes/1024;Posted 1 year ago # -
Codemattic
ModeratorWell if its a compressed pvr file then the you cant just use the formula width * height * bitsPerPixel/8
"I read somewhere that PVR files do not get uncompressed because the hardware inside the iPhone/iPad handles the data directly"
Yes thats the benefit of compressed pvrs. Its a lossy compression format that uses hardware acceleration.
Posted 1 year ago # -
A PVR texture ALWAYS compresses to a determinate size.
A 2bpp PVR texture will occupy width*height*(2 bits) of memory.
A 4bpp PVR texture will occupy width*height*(4 bits) of memory.There is never any variation in memory footprint. A 128x128 2bpp PVR texture will always occupy 4096 bytes, regardless of the source it was compressed from (how nice it looks is another story).
Posted 1 year ago # -
Ricardo1980
Member@Karl, that's not really true.
You can store images in RGB565 or RGBA4444 inside PVR, which is not compressed (apart from compressed ones, as you said), I think the word in English is quantization or something like that, I don't remember.My question is: Cocos2D can load those formats?
Posted 1 year ago # -
Ricardo1980
MemberLook at this picture:
http://img143.imageshack.us/img143/6064/dibujoupw.png
PVR is not a format, but a container (similar to DDS). PVRTC is a compressed format (similar to S3TC).
You can save images inside a PVR file in a many formats, most of them are uncompressed, see this picture.
Posted 1 year ago # -
@Ricado1980
Who's using PVR for any other format than PVRTC 4bpp or 2bpp ? Could you post a link that describe the benefits of it ?
The only supported PVR formats in cocos2d are:
* PVRTC 4BPP
* PVRTC 2BPPI suggest using .PNG if you want any other type of formats.
For further info see:
http://github.com/cocos2d/cocos2d-iphone/blob/release-0.99.3/cocos2d/CCPVRTexture.m#L121Posted 1 year ago # -
Who's using PVR for any other format than PVRTC 4bpp or 2bpp ? Could you post a link that describe the benefits of it ?
Self-answer: I guess the benefit is that it will load the textures much faster, since there is no need to decode the data, since the data is already stored in texture format.
@ricardo1980: From which tool did you take the screenshot ? Thanks.
Posted 1 year ago # -
@riq, I think that screenshot is of the texture tool available from the PowerVR Imagination Tech SDK:
http://www.imgtec.net/powervr/insider/powervr-sdk.aspThe promise of loading texture data directly to the chip is really intriguing. It could potentially save the double/triple memory usage that is currently required to get a texture from bundle to gl memory.
I'm still with Karl however in regards to the memory used to hold a given texture as the following:
memoryBytes = width * height * bitsPerPixel/8; //Converting to different units is simple: memoryKBytes = memoryBytes/1024; memoryMBytes = memoryKBytes/1024;Take a few examples to illustrate this:
1. 32bit 512x512 = 1MB
2. 16bit (RGB565 or RGBA4444) 512x512 = 512KB
3. 4bit compressed 512x512 = 128KB
4. 2bit compressed 512x512 = 64KBSo regardless of the potential optimization in loading efficiency that a PVR container may offer, the end result is the same... A fixed amount of memory used that is determined by the application of a simple formula given above.
Posted 1 year ago # -
@CJ:
Thanks for the link. Unfortunately I don't have a windows machine :(
Regarding the memory, yes, it is as you both said.
Although @Ricardo1980 is correct about the difference between PVR vs PVRTC-4BPP (one is a container, and the other a texture format) I guess that when @MasterP was asking about PVR, actually he was referring to the PVRTC formats...
At least this is the 1st time that I hear that someone is interested in storing other texture formats in a PVR container... an interesting idea.
Posted 1 year ago # -
Ricardo1980
MemberAdvantage of 565 over compressed PVR is quality, no more artifacts. And advantages over PNG is faster loading time (no time decompressing PNG) and less memory used in run time.
I already modified apple loader to support these formats.
Tell me what I have to do to add my code into your engine, I will do it next week.
Thanks.Posted 1 year ago # -
@Ricardo1980: Cool, could you attach the patch in the issue tracker ? Thanks.
http://code.google.com/p/cocos2d-iphone/issues/listPosted 1 year ago # -
It seems counter-intuitive but it makes sense when you consider that these textures need to be randomly accessible (random texel access). It is critical that the compressed size not be variable. With compression algorithms that generate variable sized compressed output, you can't get at a random point in the data without first decoding everything up to it.
PVRTC can give nice looking textures at a fraction of the size in certain kinds of images, but the downside is the artifacting, which looks really bad in some cases.
Uncompressed, low bpp images spare you the artifacting, but tend to look flat because of the reduced color resolution (though 565 mitigates this somewhat due to the human eye's higher sensitivity to greens). They're fine for non-gradient images and video-gamey sprites but not usually so great with photo-realistic sources.
Here's what a good PVRTC texture would look like (go to the bottom of the page): http://developer.apple.com/iphone/library/qa/qa2008/qa1611.html
Posted 1 year ago # -
One thing to beware of when using uncompressed data in a PVR container is that the data is UNCOMPRESSED.
For example, a 480x320 image may take 103KB of disk space (taking an example bg from my game). That same image, stored as RGBA4444 or RGBA5551 or RGB565 would take up 512KB, a five-fold increase in disk storage requirements. At that rate, it won't take long to blast past the 20MB limit for 3G downloading.
Posted 1 year ago # -
@Karl good note, would zipping and unzipping at runtime negate the gains made in loading? (I suppose a test would answer that question)
@Ricardo1980 thanks for taking time to contribute to cocos2d.
Posted 1 year ago # -
Ricardo1980
MemberHi mates!
I have a legal question.
I modified CCPVRTexture.m file to load those formats, and I read in that file a legal message that says Apple allows modifications but you have to show that original message.
How should I write something similar (my English is not very good)? Can I use GPL license or anything like that?
I only want that if anybody uses my modified file, my name could be read there.Any advice?
Thanks.
Posted 1 year ago # -
cocos2d is licensed under MIT (since v0.99.3). Basically it says: do what you want, but if you distribute the sources, they should keep the copyright notice.
That a look at how the MIT license is written. GPL is not compatible with iPhone.
What I've done with CCTexture2D.m (another file licensed under Apple's license) was to add a small changelog with the changes that were made adding the authors of the changes.
Posted 1 year ago # -
Ricardo1980
MemberThanks for reply.
Are you talking about:
/*
* Support for RGBA_4_4_4_4 and RGBA_5_5_5_1 was copied from:
* https://devforums.apple.com/message/37855#37855 by a1studmuffin
*/In that case, that does not protect you if somebody deletes those lines.
Can anyone write here a copyright message?By the way, I load 5 images, 1024*1024 in RGB656, it takes 7 seconds, and loading the same in PNG (and RGB888) takes 12 seconds. Quality is practically the same, I see no differences. I think this is a good improvement.
Thanks a lot.
Posted 1 year ago # -
Are you talking about:
yes, I was talking about that. The thing is that I don't know if it is legal to modify the original license or to append a new one. That's why in this particular cases I'm documenting the changes in these files.
Posted 1 year ago # -
JonKean
Member@Ricardo1980 for your PNG vs PVR loading test, did you have the XCode "optimize png" option enabled?
Also, adding a home brew compression container for uncompressed textures is pointless, as the package downloaded from the app store is already zip compressed.
If all you want is the PVRTexTool, you can skip the larger SDK and instead grab just this:
http://www.imgtec.com/powervr/insider/powervr-pvrtextool.aspPosted 1 year ago # -
@JonKean: I've just implemented support for PVR uncompressed textures. I did some tests that compares the loading times between them. The PNG were compressed ("optimized")
Here are the results:
http://www.cocos2d-iphone.org/forum/topic/8073Posted 1 year ago # -
@XyrisKeen: Yes, I think it is possible. You'll have to replace the CCTexture2d.* and CCTexturePVR.* files that are in v0.99.5 with the ones that are in v0.99.4.
I think that that should do the trick.Posted 1 year ago # -
Thank you Riq. I'm living' on the edge using the current developer branch after all and it's working very well.
Experimenting with RGB565 for the background bitmap, and this is working on the simulator but crashing on the device.
Might this be missing a detail or option setting?`bgi = [bgi stringByAppendingString:@"565.pvr"];
NSLog(@"Loading background: %@", bgi);
// output is correct: "thisbackground565.pvr"if(bgi) {
[CCTexture2D setDefaultAlphaPixelFormat:kTexture2DPixelFormat_RGB565];
bg = [CCSprite spriteWithFile:bgi];
} else {
[CCTexture2D setDefaultAlphaPixelFormat:kTexture2DPixelFormat_RGB565];
bg = [CCSprite spriteWithFile:@"defaultbackground565.pvr"];
}`Device is 1st gen iPod Touch, current dev branch cocos2d v0.99.5-beta2, Deployment target 31, SDK version: 4.1, device os 3.1.3, Simulator is OS 4.1, PVR 565 created with PVRTexTool.
Error message:
Previous frame inner to this frame (gdb could not unwind past this frame) (gdb) continue 2010-09-13 21:07:42.616 ThisGame_2[497:207] *** Assertion failure in -[thisGame addChild:z:tag:], /Users/devName/Dev/ThisGame_2/cocos2d/CCNode.m:303Posted 1 year ago # -
Reply »
You must log in to post.