Question about compressed files

have a look at

physfs

its a virtual filesystem extremly easy to use


it features zip files and some others to tread them as source path

you can rename the pakfile extensions to whatever you want the library checks the compression file type on its own via file headers


i suggest you to use this, this saves you a lot of time

In order to get to the actual data, the file has to be decompressed. However, this can be done in memory, sometimes even without having to read all the file first. In the end you'll have a buffer (or many buffers) containing the uncompressed data in memory and you'll be able to use it for textures, models etc. The file itself doesn't get damaged and you don't need to actually recompress the data (unless you wish to save changes to the files, which is uncommon when dealing with textures or scene representation for example).

For example, If you have a LoadScene function that gets a PK3 file name and returns a pointer to a list of items from the file, then the application is ignorant to how exactly does LoadScene work - it doesn't matter to the application if the file is compressed and how, as long as the LoadScene actually reads its data successfully.

Of course, in order for this to work out properly, the portion of your program which actually loads things like textures needs to not care whether it's loading from a disk, from a memory location, or from a procedural stream like a decompressor. This is where the power of the stream model comes into play. So the texture loader will (assuming a 'pull' model, which works well for this sort of thing) ask the input stream for n more bytes, without regard to whether the input stream is going to use fread(), copy from a memory buffer, or decompress from a compressed file. Interestingly, if it does the last one, the decompressor will probably have its own input stream which it doesn't care about, so you can have compressed files in memory or on disk. This process is known as a "filter pattern".