how to determine how many memory i'm allocating

Member
Posts: 164
Joined: 2010.10
Post: #1
if i have a file.png with dimension 960x640, what is the memory allocated for this image?in the disk it takes 16k, in memory?
my application crashes because many alloc of images takes about 30MB!!!

i have readed that a texture must have power of 2 dimension so, the effective pixel dimension in memory will be 1024*1024...?
then...the count of the amount of memoey used will be:

1024x1024x32bit=33554432bit = 4194304byte (dividing by 8)=4MB
is it correct?
why 16k becames 4MB?
how to optimize the size loaded into the ram?

thanks
Quote this message in a reply
Member
Posts: 33
Joined: 2010.09
Post: #2
PVR is the only format that makes it take up less VRAM. ALL other formats need to be decompressed, but a PNG gives you maximum quality. PVR will do terrible things to your graphics, since it's using colour reduction.

If you want to use less memory while maintaining some quality, you can optimise the image beforehand with an image manipulation program. Colour reduction/optimising for 16-bit or something like that. If you can do a good enough job, you might also be able to turn it into a PVR anyway, with no difference in quality Smile

Getting graphics right is both an art and a science. You'll probably have to experiment a bit before you're happy. If you only need a gradient background, you could also just draw that through other means. If the image is only 16k on disk, I suspect there isn't anything you could generate with a few lines of code Wink

Another thing you would need to do to reduce memory usage is to use tiling as much as possible. If you are just loading full screen-sized images you are going to run out of memory quickly, even if it isn't a mobile device. Using something like Cocos2D would help you optimise things if you're doing a 2D game.
Quote this message in a reply
Member
Posts: 164
Joined: 2010.10
Post: #3
thanks for adivices, i have downloaded PVRTextureLoader from apple.
i have substitute brick.png with a spritesheet (only black&white+transparency), but the image displayed is not what i expected.
in fact as i start the application, the image ia all black with some gray on the border.
as i apply a filter, black becomes green and alpha becomes pink...
any ideas?

an image of 16k how many memory on ram will take? (i suppose 16k, but when i see allocation i see something else...)
thanks
Quote this message in a reply
Member
Posts: 33
Joined: 2010.09
Post: #4
If it's a PVR at 16k, it takes…16k Smile

Other buffering happens sometimes. There is more to a loaded image than the image data. The structures referencing them take a bit, the system may have a double-buffered view. If you're using CoreGraphics functions to manipulate the images there could easily be three buffers holding versions of your image at once.

There are caveats with PVRs: The default formats (2- and 4-bit) are lossy. There are some types of images which don't compress well. Especially ones with transparency or large, uniform surfaces will have issues if you're not careful. A sprite sheet would need a few pixels of blank space between images to not have the colours bleed into other frames.

Presentation may also be affected by mixing images/surfaces with and without alpha planes.
Quote this message in a reply
Member
Posts: 164
Joined: 2010.10
Post: #5
a png of 1024x1024 takes 4MB on memory?
but on disk it takes 16k.....why?

how can i display an image black/white and alpha taking less memory, i'm trying with pvr and PVRTextureLoader example but i'm not able...

however many thanks for all advicesGrin
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #6
(Jan 8, 2011 05:14 AM)sefiroths Wrote:  a png of 1024x1024 takes 4MB on memory?
but on disk it takes 16k.....why?

As already mentioned, because it can't be used by OpenGL in its compressed form. So once it's loaded, and being decompressed, as you've already found, it's 1024 * 1024 = 1048576 bytes * 4 bytes per pixel (32 bits) = 4194304 bytes / 1024 = 4096 kilobytes / 1024 = 4 megabytes.

Again, as already mentioned, PVRs *are* used by the GL in compressed form, nothing else can be. It's a special format; PNG is not. For PVR, the size on disk is a compressed blob of bytes and is loaded in and used in exactly the same form. I don't generally bother with PVR anymore unless I really have to, which I haven't in quite some time. I've found that it's best for large non-transparency images such as backgrounds, which tend to take up a lot of RAM, and also for "in-between" frames of animated sprites where it blinks by so fast that you don't see the horrible edges, which also tend to take up a lot of RAM.

For "black/white and alpha" as you say, you can use GL_ALPHA (as opposed to like GL_RGBA, etc.). For a 1024 x 1024 image, that should get you down to 1 megabyte of RAM/VRAM usage.
Quote this message in a reply
Member
Posts: 164
Joined: 2010.10
Post: #7
thanks, now it's all clear
Quote this message in a reply
Member
Posts: 164
Joined: 2010.10
Post: #8
do i have to write:
glTexImage2D(GL_TEXTURE_2D, 0, GL_ALPHA, width, height, 0, GL_ALPHA, GL_UNSIGNED_BYTE, data);?
the image data can be the same png as before and texImage takes only the alpha channel, or do i have to make an image oth that kind?if so, how to make that image?
thanks
Quote this message in a reply
Member
Posts: 245
Joined: 2005.11
Post: #9
If you only want to load the alpha channel into OpenGL, you'd be best to save the PNG as a greyscale image (without alpha - stick your alpha data in the greyscale channel). That makes it easy to send the data to OpenGL. If you were to use a PNG with RGBA data you would be responsible for picking out the alpha channel - OpenGL isn't going to do that for you.
Quote this message in a reply
Member
Posts: 164
Joined: 2010.10
Post: #10
ok thanks a lot
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Have Hierarchical Sprite Tree, Need To Transform Screen X,Y To Determine Which Sprite kalimba 5 6,070 Mar 16, 2009 06:31 PM
Last Post: AnotherJake