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:

TEXTURE_NAME|2029|RGBARGBARGBA....|TEXTURE_NAME|273|RGBARGBA.....|...

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.

Phillip

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

http://www.cdrom.com/pub/infozip/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.

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

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

------------------
Dance with me......

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 )

/Niels

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??

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..