I think that maybe having to develope my own database format might be a bit too much for just a game. As my quest to find a faster, more efficient way to handle game data continues I learn much.

Now here is something: the reason why I wanted to use a database might eb to only have to load a very limited number of graphic files into memory at once ( for the textures). maybe a DB wont work for that idea, but then what file format is the most compact, quick to load, but has high resolution on a windows based platform?????


to Code, or Not To Code

wouldnt storing large data sets using hash tables possibly cause multiple collision hashes in turn slowing things down because it would have to traverse a list? Unless you could be sure that nothing would hash out to the same value. I dont know, that''s why i''m asking :-)

AP: If you really wanted to, and you had a fixed number of resources you could generate a perfect hash that maps n strings into n buckets [0..n). You would have to regenerate and recompile every time you changed your pak file or the name of a recsource. (tnstaafl)

cxi2: I recommend having a look at zlib and looking in the /contrib directory for the .zip file structure. Then write handlers that pull .pcx/.bmp/.png files by filename/subdirectory that can either use the uncompressed versions or the ordinary file. If you want to play with perfect hashing have a look at gperf