I am thinking of creating a Application Extension in C++ for PAK creation. I think it'll come to handy when I'm finished as well! As of now, I have two structures. One for Header information. Second for the Structure. E.G.


public struct PAKElements {
long IndexPos; // Changes on basis of file being placed in PAK File.
char WCHAR* Group; //What group does it belong to (meshes,. textures...
char WCHAR* File; // what file name.
UINT filesize; // Helps calculate the IndexPos Offset.
};


What I was thinking the program or game would read this PAK file and be able to sort through the file faster by placing the elements in a vector. So, if the game requires to load texture "Sometexture.tga" the game would already know what position to look for because of the vector.

The PAK Data in itself would just be the file's contents placed inside the pack file - is this a right assumption? So instance, a JPEG file content would be stuffed inside the pack file. This is just what comes to mind when I think about a ZIP file. If I ZIP a directory, the files get packed (stuffed) inside the ZIP File.

Another foresight that I saw is that possibly say if I'm loading a texture file - would I acquire the offset pointing to the texture file then scan through til I hit the end of that pointer?

If someone can show me the light on this subject that'll be totally awesomeness!

-Paul

I found this site has interesting information about all sorts of files for programmers. http://wotsit.org. I was partially on a good idea simpilar to a Quake PAK file.

When I use to do PHP file uploads, all I would do is read the entire contents of the file then write the contents read into the file on the server. Is this the same method applied to PAK files? Just that it includes a lot of blocks of directory data and file data?

Yeah, archives are usually split into two parts -- a table of contents, and the actual data files.
The TOC is usually some kind of list of structures like in your post, and then the data is just the binary files all written end-to-end.
When generating an archive like this, a common approach is to first write the entire TOC as a header, then as you write each data file you have to jump back to the appropriate TOC entry and write the appropriate offset to the data (because there was no way to know the offset when originally writing the header).

At runtime, it can be handy to read the entire TOC out of the file first, and keep it around in RAM at all times. Then when you need to load a file, you can look up it's archive-offset and file-size from the TOC, and read those bytes out of your archive.

Thanks bud! I kinda felt I was thinking in the right approach for this. I can also agree with you on writting the offset because logically, to me it's like a sql database, in order for google or whatever to pull up results - the entries are queried. So, this makes a lot more sense Hodgman. I know you didn't say actually sql database but I interpret it a PAK is like a book. Table of Contents with the filenames and the offsets, then the rest of the pages are the binary file.

Also, what you said at run time makes a lot sense because it'll have more performance. I was fooling around last night with the code and just work up - perhaps maybe later tonight I'll get a managed assembly class working. I'll report soon! I need more coffee just woke up lol

-Paul

I used ifstream's rdbuf() function - I'm wondering where there be any other advice to read the whole entire file contents and place them in a const char or char* ?