Say I have a bunch of images that I want to use with my game; I want the image files to be external, so overall I have the game's executable and a directory full of images. Let's say there are 100+ images and the size of the directory is ~500 MB.

I don't want the player to easily access these image files, so rather than having a directory containing 100+ individual files, I pack all the images into one large 500 MB file: "images.big"

With compression, I can reduce the size of "images.big" to ~50 MB. So all the player needs to download is the executable and a 50 MB file.

The problem is when I want to display the images in the game, it has to decompress "images.big" which creates a temporary 500 MB file and then it has to unpack all the images into a temporary directory (taking up another 500 MB) so it can display them based on filename. The game's directory goes from 50 MB to 1 GB, and on top of that the player can easily access the image files while the game is running.

Is there a much better way to go about this, or is it really a non-issue for a game to be creating such large temporary files/directories at runtime?

  • 1
    You could compress the images individually and store them in a single big indexed file so that you can extract the ones you actually need at runtime without having to do them all together – Valerio Santinelli Nov 19 '16 at 18:19
  • 1
    Besides the great answer to compress them individually and put them into a file with a table of contents, if one of your concerns is letting the player play without having a large download, you could have a much smaller download which contained only low resolution versions of the images, and have the game perhaps download the higher resolution images while the player plays, storing them to disk in a bundled file as described, so the higher resolution images only have to be downloaded once. – Alan Wolfe Nov 20 '16 at 3:42
up vote 6 down vote accepted

You can compress images individually, then align all of those into your own data file images.big, with a header index so that you can find each compressed image at runtime.

The index will have the start point of each individual image file location and store names/ids if those as well. When you need to load "Image.png" from images.big, the index will tell you the offset and length of the compressed data for the file within the .big

  • So let's say I'm looping through a folder of 100 images (after compressing them all individually); for each image I just need to get the size in bytes and any other data I need like name, and append that to an index file. Then I just pack all the compressed images into a single file, recording the offset of each file as I do so. Then refer to the index file when I need it to extract and decompress a specific chunk of data. – SmileyNZ Nov 20 '16 at 4:56
  • I was suggesting that the index could be a header for the file, but it could also be another file. That would save you from needing to reindex everything everytime you add another file to your package and thus make the index header larger and changing every offset. – RobStone Nov 30 '16 at 17:00

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.