Best Image Formatting?

#1 I haven't timed it, but I can't imagine that it would help a lot. How many images do you have? Could some be loaded on a per-level basis?

#2 Have to watch your video memory though - if you start thrashing your cache you'll take a huge hit.

#3 Performance improvement from using uncompressed images is proportional to amount of raster data. Single 256*256 png will be slower than it could be, but uncompressed bmp in its place won't save significant amount of time. From other perspective, compression applied to small image won't save much space either, so I guess it is a question of what you prefer - smaller installation footprint over higher performance, or other way around. I would say, graphical assets shouldn't be compressed unless there is a reason for that.

#4 Well, it's more larger background .jpg images. Granted, they're probably bigger in size than they really need to be at the moment.. but it's the difference between a 500K jpg and a 10 Meg .BMP file. Most of my .png images are fine... 10K .png's vs 100K .BMPs. Just trying figure out how the whole images and memory thing works :) Was curious how much overhead was involved since it seems to always expand them out to the larger size when it loads them into memory.

#5 Compressed images load faster than uncompressed. Fewer bytes to load, and decompression is very fast. You'll generally want PNGs for TGB. If there were support for compressed texture formats those would be better, since they are uncompressed by the hardware as needed, saving video memory.

The part where loading can be inefficient is when image sizes aren't powers of two. Stick to 1024x1024 or 2048x2048 sprite sheets wherever possible to be able to predict how much RAM they use. If you feed TGB a 500x600 image it'll allocate space for a 512x1024 image (or something like that - might even be larger). Cram as much as possible into power-of-two PNGs, use power-of-two JPEGs only for photos.

Many small images also load slightly slower than a few larger ones. Each file opened is an extra bunch of seeking and processing. Games often use a gigantic chunk of data for that reason, since they can build a lookup table and seek efficiently.

But the simplest trick for fast loading is to distribute it across the lifetime of the game. If you only load what's necessary things will tend to be much smoother than if you load every datablock right before the menu. Using transition animations also has a psychological effect - players won't mind so much if something happens on the screen between levels and scenes.

Split loading into per-level datablock scripts, use transitions, merge images into large sprite sheets.

#6 @Ronny Good point, I'll need to run some tests now to see actual difference. I believe once file is accessed, reading few extra megs shouldn't add all that much to the loading time. Decompression, on the other hand, will always be there, and it is heavier for photorealistic images. PNGs might still be more efficient for flat-colored textures though.

#7 Thanks for the replies! I'll try to keep images to powers of 2, or at least reasonably close to that.

#8 No, close isn't good enough ;)

It must be exact for good performance!

#9 Yes. If it is not a PoT image, it will be resized in memory to the next largest PoT, which can kill performance.

#10 So it's the recalculation of size that really kills performance, more than the increased memory usage of say a 50x50 image using the memory of a 64x64 image? Still mostly using place holder images from the tutorial for my game, but still a good item to cover before getting too heavily into making art for it. :)

On a semi realted note, how come none of the Torque logos to add to your game are POT images? :p They're already close too! :) Heh, the horizontal one is like 493X500. It's not that big of a pain to just pad the size with Gimp, but it would be nice if they were already optimal sizes.

#11 They're components, or meant to be used as default loader images. They'll generally be unloaded before you see the menu :)

#12 Alright, it is time to close that compression topic once and for all. Here's results I've got from different compression levels:

HDD (SAMSUNG HD322GJ ATA) + Intel i3-540
bmp 1.24 ms
full photo 33.4 ms
fast photo 24 ms
full gradients 14.04 ms
fast gradients 7.08 ms

HDD (QUANTUM FIREBALL AS20.5) + AMD Duron 800MHz
bmp 7.4 ms
full photo 153.88 ms
fast photo 125.2 ms
full gradients 72.5 ms
fast gradients 45.88 ms

flash drive (SDHC class 6, USB 2.0) + Intel i3-540
bmp 0.64 ms
full photo 34.62 ms
fast photo 22.48 ms
full gradients 16.58 ms
fast gradients 8.08 ms


Explanation and details:
Images used - random landscape photographic image for 'photo', array of illustrator gradient swatches for 'gradients'.

Full compression - Photoshop's 'Save for web'; may not actually be full but still fits our purpose well
Fast compression - lipPng based gzip-only compression

File sizes:
*BMP - 2 359 352 bytes
*PNG (full compression photo) - 1 473 016 bytes [0,6:1]
*PNG (fast compression photo) - 1 938 108 bytes [0,8:1]
*PNG (full compression gradients) - 179 231 bytes [0,07:1]
*PNG (fast compression gradients) - 261 909 bytes [0,1:1]

All images are 1024x768 24bpp.

Time:
Time is average of 50 sequential loads, measured within t2dImageMapDatablock::loadSrcBitmap().


Summary:
BMPs are 6..25 times faster. Compression saves storage space, not loading time. World hasn't gone mad.

#13 Personally, I dislike JPG as an image format. No alpha. Rubbish.

#14 As far as I know, the fastest is .dds, since it stays compressed when loading, so it is from 4-8 times faster than other formats.

For images you edit only .tga and .png are recommended.