PNG or BMP

Started by
9 comments, last by Nitage 18 years, 10 months ago
Is the only reason a PNG takes up less memory than a BMP because a PNG is compressed? If I read it into my program, does it just uncompress and become as big or bigger than a BMP?
My Current Project Angels 22 (4E5)
Advertisement
That depends on how you "read" it.
Killers don't end up in jailThey end up on a high-score!
Let's say I am using SDL_image's standard way to load the PNG and use it as a Surface.
My Current Project Angels 22 (4E5)
An array of RGBA data is an array of RGBA data, no matter if it's read from a BMP or uncompressed from a PNG. ...or maybe I got your question wrong? ;)

Cheers,
Drag0n
-----------------------------"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to build bigger and better idiots. So far, the universe is winning..." -- Rich Cook"...nobody ever accused English pronounciation and spelling of being logical." -- Bjarne Stroustrup"...the war on terror is going badly because, if you where to compare it to WWII, it's like America being attacked by Japan, and responding by invading Brazil." -- Michalson
I dont know much about SDL,

However, if the image is...say... 24 bits per pixel, than chances are *unless sdl is using some hardware driver texture compression(doubt it)* then your image will be roughly:

(3*width*height) bytes, which is equivilant to just storing the color data with no compression.

So PNG will save you space while in disk format, but when loaded it is likely to be the size of it's raw color data equivilant.

however... you don't think that disk compression is worthless, because the less data you have to read off the hard disk (smaller if it is compressed) the faster that will happen.

so even though it may be:

HDD to RAM
500k to 3MB

it is 'probably' better than:

HDD to RAM
3MB to 3MB

Since you are reading less data off the HDD.

Be aware that this is not always the case with all image formats though.

Unlike raw uncompressed image data, compressed data needs to be uncompressed, which in some cases can be very complicated, and can slow things down.

in the case of PNG though I dont belive this is so.

Raymond Jacobs, Owner - Ethereal Darkness Interactive
www.EDIGames.com - EDIGamesCompany - @EDIGames

Thanks, I never really considered that no matter how big the file size is on disk that it would be in the same format and therefore the same size when I load it up.
My Current Project Angels 22 (4E5)
... Unless you're using compressed textures on your graphics card.

(of course, these are not PNG format)
I dropped PNGs from my game engine because I assumed they would take longer to read than TGAs/BMPs due to having to decompress them.

Does anyone have any data regarding how long the extra disk access time is compared to how long it take to decompress a PNG? If not, it will have to go on my 'To be done when I have lots of free time list'.
Quote:Original post by Nitage
Does anyone have any data regarding how long the extra disk access time is compared to how long it take to decompress a PNG? If not, it will have to go on my 'To be done when I have lots of free time list'.
This is half guessing: AFAIK, PNG uses ZLIB for the compression, and so did Doom 3. If you manually extracted Doom 3's pak files, disk space usage grew from 1,3 Gig to 2,5 Gig or something, but the game began starting up and running a lot faster. So if they indeed use same compression algorithm, this indicates that reading BMP would be faster. (at least if the compression rate is so small.. This again has some impact of course)
Quote:Original post by Nitage
I dropped PNGs from my game engine because I assumed they would take longer to read than TGAs/BMPs due to having to decompress them.

Does anyone have any data regarding how long the extra disk access time is compared to how long it take to decompress a PNG? If not, it will have to go on my 'To be done when I have lots of free time list'.


PNG graphics are standard for cell phone games done in J2ME. I think your desktop can handle them reasonably well. I/O can be pretty reliably counted upon to be the bottleneck regardless (and there isn't really anything you can do about it either).

This topic is closed to new replies.

Advertisement