hi, I''m finding that the files I generate for my levels are getting too big (up to 5meg a level) so I need to investigate compression. I dont have time to write my own compression algorithm - so I was wondering if anyone can point me to a place I can get an open-source/freeware compression utility that can be used through code... Also, is the code for making ".pak" archives (as in Half-life) available anywhere? cheers; Jack,

zlib will get you the compression. There are links to parse/generate the pkzip style directory structure, this often makes sense for games that would be just as happy with a bunch of files, rather than a database like structure. the quake/HL/about_half_the_FPS_out_there .pak format is documaented, don''t know where off hand though.

cheers

I''ll go check it out now...

Jack

The Quake/Half-Life etc... pak format is not compressed at all. I think they were going to implent compression for the HL paks, but I guess they never got around to it.

-e

It might be a better idea to investigate how you can represent the data better, rather than trying to compress the data. ie
using char''s instead of ints if the values are always with 0-256

If you put your data format up here, I''m sure we could suggest improvements....




Game production:
Good, quick, cheap: Choose two.

okay;

the Zlib recommended above screwed the files up. The files were corrupt after compress-decompress...

the data is basically an array dump. values for a 400x400 array; but all values are float/decimal: -0.001, -1.6 and so on

they are values for heightmaps and lightmaps, there''s about 160,000 entries..

currently eacvh value is written in and seperated with another character (currently "A"): so it looks like

-0.98A-0.01A1.0A-0.26A-0.5

and so on for 900kb to 2mb depending...

Any ideas?

quote: currently eacvh value is written in and seperated with another character (currently "A"): so it looks like

-0.98A-0.01A1.0A-0.26A-0.5

and so on for 900kb to 2mb depending...

Don''t save the data as text, instead as binary data. So, instead of converting the float (let''s call it fx) to string and then writing that to file, using fwrite you would do like this:

    fwrite(&fx, sizeof(float), 1, File);    

-Jussi

Do you really need floating point accuracy ? How about using unsigned short ints instead ?

If you maximum height value was 1000, a 16-bit short int would give you a precision of around 0.001, ie if your highest cliff was 1 kilometer high, using unsigned short ints would give you a precision of around a millimeter. ( or an accuracy of 0.002 if you wanted to go from -1000 to 1000.

The same could apply for lightmaps, and so your data size would be 400 * 400 * 2 * 2 = 640,000 bytes.

oh and definitely use binary files as Selkrank said.

btw exactly what do you mean when you say ''lighmaps'' ? Do you mean you store the light that that vertex should be at ?


If you wanted to be really clever, you could use a DCT compression ( the type of compression used in JPG''s ) on your heightfield, if you didn''t mind it being slightly lossy.

ZLib is quite widely used in many successful projects. Are you sure you''re not doing something wrong?

Thanks very much;

I''ll sort out the binary thing...

The landscape heights are read as a 0-255 value froma greyscale bitmap - and then put into formula:

-10 + (0-255 value) * 0.05

to get the overall value used in D3D

the lightmap is basically the colour of each vertex in the world - I''m using "LVERTEX" - so I specify my own lighting...

I''ll try the ZLib thing again - I have no reason to "distrust it" but it did mangle the files...

Jack,