# What is the state of the art at shipping game graphics such as lots of small BMP files?

We have lots of small BMP files which I think would be easier to copy if we had them combined in a big TAR/ZIP/whatever.

What is the state of the art at shipping game graphics?

We are using C# and are aware of zlib. Just brainstorming to see if there are any other solutions better than zlib.

• You want to ship .bmp files? – Bobby Jan 8 '12 at 14:14
• You prefer png? – foobar Jan 8 '12 at 23:27
• Hell yes...it's not only smaller (by far) but you'll also get free 8-bit transparency on top of it (jpg might even be much smaller then png, but png is lossless)! – Bobby Jan 9 '12 at 7:28
• 32bit bmp has the transparency too. Png is just a compressed bitmap anyway. Compressing bitmaps as a whole pack VS. compressing them on the individual file level shouldn't have that much of a difference in terms of "size on HDD". Access speed is another question though... – foobar Jan 15 '12 at 1:25

You could also look into SharpZipLib or DotNetZip - DotNetZip gives you access to a Stream directly, which is helpful as most C# libraries out there can load from streams (as opposed to files). Furthermore DotNetZip uses the Ms-PL (BSD-Like), instead of the GPL with a legally questionable exception.

Another option is to use texture atlases - instead of having many small images have a few big ones. These actually load slightly faster and are slightly faster at runtime if you get smart with how you draw them.

Finally you could run each asset type through the relevant lossless compressor (PNG, FLAC, etc.) and store them in a flat file (basically a zip file with compression disabled). Remember to avoid compressing compressed data, as that will increase the size in most cases.

Some prior art:

• MPQ: Probably as good as it gets for game assets, the lookups are designed to be fast (disk-based hash-table etc.). Each file type (that is supported) has a unique compressor.
• Quake PAK: This is basically a flat file structure.
• Doom WAD: Somewhat specific to Doom, but worth looking into.

An option is to store images in the same compression format that you use for making compressed textures. This has the advantage that you are not going to convert fro one lossy format to another, yet you store the data in a lossy format. Depending on the textures there may still be something to gain by storing such files in a compressed archive.

ZLIB could be a good answer, but if you're aware of people opening grabbing your assets, you could also make your own file format to store your assets, its not that hard though.

Here's how you can make it: http://content.gpwiki.org/index.php/C:Custom_Resource_Files

It is in C, but should not be that hard to learn, as C# is some like C and C++.

Of course, people that still have higher knowledge can catch your resources, you can add little encryption if you want, not too hard.

This can be very useful, but it will just join your files. For compression too, you have two choices.

1 - Make your entire resources file, compress it, and ship.
This Method is easy, but not very good, you should uncompress everything if you want to take just one resource.

2 - Compress every resource, and add they compressed to the resource file.
That's pretty good too, you'll have a slight increase in the size beside the method 1, because each file is compressed separately, but its better if you want flexibility.

Each method has its own drawbacks, you should choose wisely. Generally, if you game has a pretty low number of resources, method 1 should be better, If you have LOTS, the method 2 should fit you, because the size of all resources together will overwhelm the extra that you gain.

For compression libs, you have:

• The most famous medium, Zlib
• The one with the faster decompression, LZO
• The great compression ratio, 7-Zip

I would go with LZO if I want fast access ingame, so you have not to fear about uncompressing in real time, 7-Zip if I want the files to be shrinked A LOT or Zlib itself if I want balanced decompression ratio and size.
The choice is yours :D

Ah, of course there are others algorithms to compress data, and you can find those googling.