Sign in to follow this  

Here a simple to learn & free file packing library

This topic is 4824 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've developed a simple to learn and quite complete file packing library, with 3 different compression algorithms from ZLIB(ZIP like compression), LIBBZIP2 and UCL. You can archive, load, move, sort, replace, swap files and add buffers, comprime them or load directly in memory. It has a C++ Classes structure and it's easy to learn. It's useful when you make your game and you want to pack all images and data in only one file! If you want to download it go HERE ! [Edited by - BioLich on September 18, 2004 12:10:46 PM]

Share this post


Link to post
Share on other sites
Sounds cool, tho you may wish to state what its 'good' at and what its 'poor' at.
Does it have a fast random file lookup time? Does it support fast file insertion, or replacment with a larger or smaller file? Does it support fast deletion without leaveing 'unused' space that may linger around, and if so, does it provide a way to 'clear' this lingering space, and if so, does it do so in a fast or slow way? While 'fast' and 'slow' may be highly realative terms, you can usally call something 'fast' if it does things in a very limited number of operations, and 'slow' if it requires a large amount of operations, usally dependant on how much data there is.
Ie, a fast space clearer would move the end of the file into the 'free' space and shink it, a slow one would just move all parts of the file over. (Sounds like 'fast' is allways better right? Not so, because some methods of storeing files may require they are all in one sized chunk, or in a certen order)

Basicly, tell us what its designed to be good at, and what has suffered because its been designed to be good at something else.

Share this post


Link to post
Share on other sites
I've developed PK3 Library thinking on what could be useful for my games (I always "hated" leaving all the images and sounds on many files).
The main goals I wanted to achieve were:
* Small use of memory. (maybe in a next version I'll also make the size of the memory block (used for I/O operations) customizable)
* Implementing some good compression algorithm.
* Creating an easy to use interface.
Thinking about games and speed I suppose that the thing that really matters in an archiving library is the loading speed, even if the other features are important too.
I also decided not to include encryption or encrypted hashes (SHA-1).

A PK3 file is structured in modules:
[FILE HEADER]
[FILE DATA]
[eventual ADDITIONAL DATA]

So file insertion is 'fast' because the file is simply added at the end of the archive.
Retriving file informations is quite 'fast' becuse the file header has fixed size and all the headers are loaded in a table, like the offsets where the data begins.
Retrieving files and/or their headers can be done by knowing or using the file index or with GetFileIndex(LPCSTR* szName, UINT uiStardIndex=0) function that supports also the "*" as jolly character.

The archive management operations like moving, replacing, sorting..etc.. can be done in two ways:
The first is virtual, and it's really 'fast'. For example you can sort with a your custom sorting procedure only the table of indexes and not really the archive saved in the disk.
The second way is the real one and it can be defined 'slower' because require more operations.
One way to speed up operations is to do all the management operations in "virtual mode" and only at the end rewrite the archive.

When you rewrite the archive with RewriteArchive(), the library will create a unique temp file that will replace the old archive at the end.

Other features of the PK3 Library are the attributes and the additional data.
1. You can set up to 20 attributes for each file with your custom values in order to separate files in types or other things. For example the textures of one level can be defined with the same value in one of the attribute.
2. Suppose you want to save this struct with the file
struct
{
char szFilePath[100]; // It stores the original file path
SYSTEMTIME st; // It stores the time when the file was created
...
}FileInfo;
You can save this struct FileInfo as additional data for one or all files after you've filled it with the info you want. This additional data can be easily retrieved and used.

Claudio

Share this post


Link to post
Share on other sites
Would be useful if I create a direct support for image loading (JPEG,BMP,PCX,TGA) for the library?
It would make easier creating textures and other things in few lines of code..

Share this post


Link to post
Share on other sites
Try not to make the library into one that tries to do everthing - intead concentrate on making it the best possible archive library you can, then if you want you can always write a wrapper library to load images etc.

Share this post


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