http://advsys.net/ken/utils.htm
Ken, creator of Duke3d's build engine has a useful PNG optimization program that can help reduce your overall graphical resource impact, although I doubt it will have any effect on game/program performance. Could be ideal for porting to devices that have limits on storage space or generally keeping your program's resources smaller.
Silly question, but does reducing the file size of an optimised .PNG actually make any difference in a zipped file? I bet it doesn't.
The reason I ask is that a .BMP when zipped is generally smaller (sometimes significantly) than the same image in .PNG format so technically, reducing a .PNG only saves memory when extracted. For a smaller download, .BMP is often better. So it all depends when and where you want to make an image's memory size smaller.
AFAIK, the PNG internally just does zip up the image line by line (thus slighlty better compression of BMPs). The use of PNG compressors will reduce the colour space to 16 or 8 bit if possible w/o changing the resulting image.
Also, there's an option to change "close" pixel colours to slightly different ones that seem to be better compressible.
Actually Gernot, PNG compression is worse than .BMP compression.
Try it - choose any large image. Save in .BMP and .PNG. Now compress the .BMP in .RAR or .ZIP - the compressed .BMP image will be smaller than the uncompressed .PNG image. Compress the .PNG image and the compressed .BMP will still be smaller.
.BMP compresses better than .PNG pretty much every time.
Ever tried 7zip with bmp? :-)
Quote from: Moru on 2010-Feb-02
Ever tried 7zip with bmp? :-)
Nope - I always use WinRAR.
thanks 4share
Ian Price: What I think Kitty Hello is trying to say is that .PNG themselves have a better compression algorythm, making a PNG itself better compressed than a BMP, not better TO compress ;)
Sorry, Hooka, but that is not correct, or what I was saying.
It's obvious that an unzipped .PNG is smaller than an unzipped .BMP (that both have the same image). But just zip up the .BMP and leave the .PNG as it was and the zipped .BMP will generally be smaller than the .PNG.
Therefore .PNG compression IS NOT better than .BMP compression. I have tried this with multiple images of varying sizes and 99% of the time a zipped .BMP will be smaller than either a zipped or unzipped .PNG.
Todays compression algorithms are usually best applied once. If you compress something already compressed you will most of the time not get a better result. More likely a worse result. So if you want a small distribution package, go for BMP, if you want small size on the installed game, use PNG with compression. On the other hand, most people don't care about either nowadays with flatrate 100 Mbit internet connection and 2 x 1.5 Terrabyte harddrives... :-)
But whatever format you choose, the memory footprint will be roughly the same when running your game.
Indeed, once in the game the memory used will be the same - it's just small size for distribution or small size on your HD/memory card.
QuoteSo if you want a small distribution package, go for BMP, if you want small size on the installed game, use PNG with compression. On the other hand, most people don't care about either nowadays with flatrate 100 Mbit internet connection and 2 x 1.5 Terrabyte harddrives... :-)
Bloat because you can is never good and it matters now, more than it ever has before.
I cared about it a lot more when I had a 300 baud modem than now when I have 100 Mbit... If a download is 4 MByte or 750 MByte doesn't do that much difference in time any more. And in the case of 750 MByte it's most likely a linux distro so I can just burn it and delete it. Next time I need it I need to download a new one anyway since it was updated again :-)
Moru: Not everybody has 100Mbit connections. Many of those who do, can't actually use them. Many in Europe still do not have unlimited bandwidth ISPs. Some of the ISPs that offer unlimited bandwidth have caps in the small print of the ToS. It is not any different here in the USA.
You also need to remember many of the systems our EUs are using are systems that have limitations similar to 10 year old systems. Netbooks are a huge market, and people do play games on them. Many of the original netbooks out there only have 4GB- 8GB hard drives drives. Most current models now have 120GB-160GB hard drives, but that is still pretty small by the time you put Windows and a few office apps on it, there isn't room for a lot of games. Desktops are no different. People are increasingly moving to SSDs. The affordable and reputable SSDs are around 80GB. Extremely limited space. GLBasic games will run fine on any of the systems mentioned in this paragraph. The only thing at a premium is space.
Also, EUs are increasingly moving to portable apps. Again, limited space on portable drives.
Tablets are making a comeback, but with reduced capacity.
Distribution size for games and apps should be a major concern for developers. It will continue to be a concern in the future as long as technology continues to progress via addition by subtraction.
Yes, I guess I'm still in the stone age being spoiled since 10+ years with 100MBit internet here in the forests of northern Sweden :-)
And the sort of applications I do, grafics are such a low concern that it won't change the size of the app much...
Quote from: Moru on 2010-Apr-19here in the forests of northern Sweden :-)
Such a lovely country. Many years ago I spent a little bit of time at Muskö naval base getting something I can't talk about repaired while we were doing something I can't talk about and had an incident I can't talk about that damaged the first thing I can't talk about. Lovely and very hospitable folks at Muskö. Muskö was the most impressive non USA underground military facility I have ever seen.
That's ok, it's not secret any more :-)
http://www.militaryphotos.net/forums/showthread.php?65025-Musk-underground-navalbase
The top pictures are gone, it's an old post but search on google, you find lots of movies on youtube too.
I like PNGs because of their loss-less compression, and they help in reducing overall program size on disk, but is there an improvement in the time it takes for loading graphics if you use uncompressed BMP files?
Quote from: Scott_AW on 2010-Apr-22is there an improvement in the time it takes for loading graphics if you use uncompressed BMP files?
Yes, but how much faster can really vary.
Well I can check it out later tonight and see.
The tech demo I have below(PC & OSX) uses 27 1024x600 24bit png images, it eats a bunch of loading time. So I can try converting them to BMPs and see if there is any improvement from it.
http://www.glbasic.com/forum/index.php?topic=4413.0
Got a chance to check it out...
So with my demo using 37 1024x600 images:
BMP(24bit)
Total Size = 46mb
Zipped Size = 3.6mb
Game Loadtime = 4 seconds
PNG(24bit)
Total Size = 5mb
Zipped Size = about the same
Game Loadtime = 4 seconds
I guess the next thing to check would it be beneficial to degrade the color capacity to 8bit colors for further performance. At least done to the tile layers but not the glow layer(would kill the gradients). Anyone know if using 8bit images has any effect when loaded into the game than higher bit rates?
QuoteI guess the next thing to check would it be beneficial to degrade the color capacity to 8bit colors for further performance.
In general, loading an 8 bit BMP is slower than loading a 24 bit BMP. But, it may not be much of an issue anymore.
In the old days, you would never use JPG or PNGs in a game or app. Loading speed was slow because of decompression time. Now with modern processors and multicores, it may give you almost no penalty due to fast modern CPUs, but that's an entirely different thing. Compressed images should never give you better performance than a 24 bit BMP, but it can give you equal performance.
8 bit BMPs used to always be slower and something to be avoided because the palette has to be read before the image can be displayed. 24 bit BMPs don't have a palette, and load very fast. However with modern processors and operating systems, the palette handling could easily be pushed into its own thread or even another core to give a speed boost. However, 8 bit images were smaller and were widely used in gaming for that reason alone even after 24 bit hardware became mainstream. Distribution size was/is always important (which is why people will still use 24 bit BMPs over JPG or PNG as 24 bit BMPs compress smaller for distribution).
I didn't take into consideration the palette part, but that does make sense.
Also an 8bit PNG can be larger than 24bit PNG, most likely due to the palette data.
Previously when working with 8bit graphics I was using GIF files, since they are pretty nice for limited colors and produce smaller files in that regard compared to PNGs. That and animation capabilities. Both can have transparent backgrounds. However it seems that GIF support is dying out.
I recall in the past GIF was kind of a dead fish due to some very strict and stupid license it, preventing it from really moving beyond a simple web graphic. That expired many years ago, but too late really.
I wrote a GUI wrapper for OptiPNG. Simply drop your PNG's into the input directory and run the gui. Hope some of you find it useful.
[attachment deleted by admin]