Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!

We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.

Compression file.,...

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:


Posted 22 October 1999 - 06:18 AM

I am making a strategy game and for the graphix engine i want it to read a compressed file that has bitmap files in it(example... .grp(starcraft)) and i wanna make an editor that does it. i want the compressed file in this format bitmap 1 bitmap2 ....and so on.So basically all it will be is basically a .zip file that is compatible with my game. So does any one now any i/o functions or anything that would compress the bitmaps into a simgle file. Anyone have the least bit of an idea??


#2 Phillip Schuster   Members   -  Reputation: 122


Posted 21 October 1999 - 10:28 AM

Hi !!

Well, it's quite simple. I would take the following way:
Create a texture-editor which loads in BMP-Files and saves them in their raw pixels (so, for example for 32 Bit Texture : RGBARGBARGBA... each of them is one BYTE). Then, create a big file, start with the bitmap name (you could set a limit to the texture name) then print the size and then save the bytes of the first bitmap, then go on the same with the second. This will compress all bitmaps into one big file, which would look like that:


If you want to load a specific texture, read the name of the first texture and compare, if it's not the texture, seek about the size of this texture forward, then read the next texture-name, until you found it, then get it's size, and read all bytes into a buffer, using this buffer then copy the bytes into a DirectDraw Surface for example.


#3 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:


Posted 21 October 1999 - 11:48 AM

Do you want a compressed file or a packed file? It sounds like
you want a compressed file. Take a look at zlib:


If you are talking about compressed files, this usually involves
encoding and decoding schemes.

Packed files are usually just a container to hold the individual
files unmodified (they can compressed or uncompressed). Which is
good if you want to create some sort of file packer program to
quickly add and remove files without touching them.

#4 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:


Posted 21 October 1999 - 05:19 PM

Your right a packed file is what i want. i dont really care about compression file. @ both of you Thanx for your help

#5 CJ   Members   -  Reputation: 122


Posted 21 October 1999 - 10:10 PM

Hmmm....bitmap files 24 and 32 bit are both BGRBGR instead of RGBRGB......just a sidenote

Dance with me......

#6 Niels   Members   -  Reputation: 122


Posted 22 October 1999 - 02:07 AM

I wrote a small tool that reads in the output directly from a 3D package (.tga), crops the images, order them by size and paste them into a new image. The new image is written back in either .tga or .jpg format, along with a set of .txt files describing the location, size, name and center offset of each of the original pictures.

(That's what happens when a programmer get's tired of cropping 1200 animation frames by hand )


#7 Sphet   Members   -  Reputation: 631


Posted 22 October 1999 - 06:18 AM

I think the packed method outlined above is on the right track. Personally though, I would break your file into two. One file would be the index, and the other would be the data. This makes searching for specific data much faster.

If your index file is limited to having only one type of data in that is defined as the following:

typedef struct _packedIndex
int resource_id; // unique id
char name[20]; // name of resource
unsigned long offset; // offset from start of file
unsigned long length; // length of data segment

The index file would just contain all the structures pointing to the data in the packed file. That way you can search much more quickly for specific data either by name, or by unique ID. The unique ID works well if your packing program is able to output an RESOURCE_INDEX.H file or some such that you can then refer to certain files by #define. In my reosurce packing utility I have a text input file like this:

# each line is a seperate entry
# resource name, resource path
INTRO_SCREEN1, C:\data\images\intro8bit.bmp
INTRO_SCREEN2, C:\data\images\intro24bit.bmp
GOLD_MINE, C:\data\images\sprites\goldmine8.bmp

Once the program reads this and puts together the resource.pak and resource.idx files, it ouputs an include filecalled "packed_index.h" that ,looks like this:


// resource IDs

#define INTRO_SCREEN1 0
#define INTRO_SCREEN2 1

and then I can load it in my function as

ret = LoadPakResource(INTRO_SCREEN1)..

my LoadPakResource then looks in the resource.idx for entry 0 (that's what INTRO_SCREEN1 is defined as), reads that and finds the offset in resource.pak .. it then opens resource.pak, seeks to the offset and loads the length variable worth of data..

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.