Jump to content
  • Advertisement
Sign in to follow this  
Paul C Skertich

Does this sound like the right ideal for PAK?

This topic is 2216 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!