Compression and encryption are different things AFAIK, so why even use compression if you have to still decompress anyway, is this just to reduce distribution size or is there some other reason?
Mainly compression is used to reduce the size of the distributive and game resource package. You should distinguish compression of the distributive and the resource package of the installed game. The distributive usually is compressed by high compression ratio algorithms, while the package of installed game can be compressed by algorithms with fast decompression speed to be able to decompress it on fly. For the distribution there is only one benefit - reduction of its size. However, for the package of installed game the benefit is not only a reduction of its size, but also possible a light speed up of file read operations. The resource package of the installed game might not be compressed, it is not always necessary.
The speed up of read operations could be achieved in case of slow disk read operations (mobile devices for example) and using algorithms with very fast decompression speed, such as LZ4
On mobile devises, I have noticed the following thing. The ratio of read time of compressed data to decompression time with LZ4 can be up to ten times. So depending on compression ratio, you can chose what types of files should be compressed and what not.
You should be aware of the following disadvantages of on fly decompression:
- It is hard to implement streaming of compressed data and there could be serious loss of performance.
- Memory consumption would be increased due to the need of allocating buffers for decompression.
Mainly compression is in fact used to reduce distribution size.
If you think about it with digital music, you could download a CD as .wav and it's 650 MB, or as 256 KBPS AAC files and it's 1/5 the size with the same sound quality*.
It just makes sense to compress anything you can. You're taking the compression time on your side once to save time downloading or reduce storage media size for everyone who uses the product.
As a side note, yes encryption is different from compression. Encryption makes it hard to read the data if you're not the intended recipient. When making an iOS game, we send a compressed archive to Apple, then they encrypt it, which makes the package bigger.
* I have done blinded testing on this. There's no discernable difference between uncompressed audio and 256 KBPS AAC audio.
A big reason to compress game assets is to decrease loading times.
- Read uncompressed asset of 20MB size, or
- Read compressed asset of 10MB size and decompress.
In scenario 2 less data needs to be read from the hard disk which will save some time. If the CPU is faster at decompressing the read 10MB to the original 20MB than the hard disk in scenario 1 is capable of reading the remaining 10MB, compression will improve the loading time. Note that hard disks are generally much slower than CPUs. Many algorithms (you mentioned zlib's) even allow decompression on the CPU while the hard disk is reading in parallel.
You should pick an algorithm that
- compresses well (to reduce the time spent reading from the hard disk) and
- decompresses quickly (to reduce the time decompressing using the CPU).
Algorithms that would increase loading times are used when compressed size on disk is more important than decompression time, for example during installation of the game assets.