The idea is that you have one file (data file), in this data file there is a directory or index of all the other files (resources) this file contains.

Part of the information contained in the index is the offset within the data file your resource file resides, and its length.

So, when you need a particular sound, image, or whatever, you open your data file, lookup in your index for the offset of your file, seek to that offset, and begin reading as usual.

The sample code I pointed you to has a couple of limitations that may make it inappropriate for your use:

1) Fixed index size, indicating the file can only hold so many other files. You can set this number to any arbitrary number i guess, but once your out of "slots", your out..

2) There is no compression

For another example, check out Chris Hargroves colum "Code on the Cob" at www.loonygames.com. Or, I believe there is a similar example as part of the DirectX SDK examples.

-mordell

Sure...!

First I would recommend building the ures.cpp executable. It is the tool that you would use to build your .res file.

Once you have the URES.EXE compiled, you can create the URES.RES resource file.

Simply run the URES.EXE with the command line option -c. This will create the file URES.RES in the current directory. (NOTE: you can also just run URES without command line options to get a list of available commands).

Now, you can add your resources to the URES.RES file by using the command line option:

URES -a -ntitle.bmp -ktitle

This will add the file title.bmp to the resource and give it the key of "title". Keys MUST be unique as URES will fail to add if the key already exists for an item in the resource file.

Go ahead and add all the files you need:

URES -a -nsprite.bmp -ksprite1
URES -a -nexplosion.wav -kboom1

Once you have added all your resources you will be ready to use the URES.RES file.

Add the files resclient.h and resclient.cpp to your project.

Probably during the initialization of your program you will want to read out the files you will need. To do so, create an instance of the ResourceClient_t class, call its extractResource with the the appropriate key for the resource your looking for, and the filename you want to refer to that resource.

Like so:

//: assumes URES.RES in current directory
//: otherwise, if you renamed your res file
//: to something else, or its in a different
//: dir, you would use alternate ctor and
//: pass in path+filename of .res file.

ResourceClient_t rc;
returnValue rv;

rv = rc.extractResource("title" /* key */, "BMP\\title.bmp" /* output file */);

check rv for errors.

//: continue for all resources...
rv = rc.extractResource("sprite1" /* key */, "BMP\\sprite.bmp" /* output file */);

rv = rc.extractResource("boom1" /* key */, "BMP\\explosion.wav" /* output file */);

[...other files...]

The resource(s) will be created in the BMP directory off the current directory, if this directory doesn't already exist, the extract will fail (sorry, beyond the scope of the current implementation).

You would then make the call(s) to DDLoadBitmap (or whatever else) and the files would be there.

Now, one thing (of many) I didn't do, but you will want to do, is to keep a list of the files you use (extracted) and delete them all when you are finished. That was left out of the ResourceClient_t implementation (oversight).

As you can see, there are lots and lots of features that would make this so much better, but there you have it.

Let me know if its still not clear, or if you have other questions and especially if you make improvements I would like to hear about it!

-mordell

The URES source needed to be able to extract files out to a temporary directory, where another process was expecting to find them.

Reading directly from the resource file would be the preferred method. I believe there is an example of this in the DirectX sdk (under fastfile or something like that), as well as part of Chris Hargroves "Code on the Cob" code on www.loonygames.com.

-mordell