Anyone know where I can find some information about this API? I am finding it very difficult to gather information myself. I have the masm inc file which tells me how many parameters each call requires, I have no info as to what these parameters are or how to use them for my own needs. I realise that there exist tools that already do this for you and that those tools do their job very well, still I want to learn how to do this myself.
MSDN: http://msdn.microsoft.com/en-us/library/aa365224(VS.85).aspx
Thanks stormbringer but I already have this information. There are more functions that I cannot find at msdn. Here is the functions in LZ32-
CopyLZFile, GetExpandedName, LZClose, LZCloseFile, LZCopy, LZCreateFileW, LZDone, LZInit, LZOpenFile, LZOpenFileW, LZRead, LZSeek, LZStart
at msdn I can find only information about these functions -
CopyLZFile, GetExpandedName, LZClose, LZCloseFile, LZCopy, LZInit, LZOpenFile, LZOpenFileW, LZRead, LZSeek
LZStart and LZDone dont need any parameters but LZCreateFileW needs 5 params
Examples are few and far between I cannot find any
rain_storm: which functions do you need an example for?
here is one I found : http://www.winehq.org/pipermail/wine-cvs/2006-June/023850.html
Usually Wine is a good source for having an inside look at the Win32 API....
also normally function names ending with a "W" take strings as "wide-char" instead of simple "char", that's it. It's just Win32 for Unicode. So normally you should just pass a wide char string instead of a char string (usually for file names, etc). It should have the same number of parameters.
Let me know if you get something working, otherwise I'll dig a bit more..
Thanks that looks useful I would prefer asm but the parameters are the same so cpp will have to do, now I have something to work with I will ask if I get stuck on anything
For NT if you use the W versions of the functions the strings often have to be dword (32bit) aligned, even though the characters are only short (16bit). But I guess if you're size coding you won't need the W versions. :D
Jim
From what I can tell you just need to LZOpenFile on a compressed file then LZCopy file will decompress the file and create an expanded copy. I think LZStart + LZDone is used to compress an uncompressed file can anyone verify this?
GetExpandedName sounds like its useful here it accepts a compressed file name and expands it to its uncompressed form but I think it might be better to just name the file a.bin
Ideally I would prefer to use a pointer to memory instead of a file handle but I dont think that will work. I can live with compressed data files lying around in the folder for now.
do you intend to make calls to this DLL for some small-sized intro? Otherwise you can use zlib (which does the same thing), or maybe even better, rewrite an assembler version of the LZW compression in GIF. I did that a long time ago in MC68000 and it's quite small code, and fast. But you cannot use it for commercial code :(
Nice tip with the zlib sounds much better. I am looking at the pseudocode on the wiki it isnt all that complicated - http://en.wikipedia.org/wiki/LZW
This is the decompressor which has a safety net that can be chopped out -
read a char k;
output k;
w = k;
while (read a char k) do
if (index k exists in dictionary) then
entry = dictionary entry for k;
else if (index k does not exist in dictionary && k == currSizeDict)
entry = w + w[0];
else
signal invalid code;
endif
output entry;
add w+entry[0] to the dictionary;
w = entry;
done
it may be worth while doing this by hand cos its one less library to import and make calls to. I want to have a routine that can open compressed files for textures + music etc. It would also be nice to be able to decompress code with the same routine and a bonus if the external files can be done away with and data included inside the exe itself. I will have a stab at LZW routine see what progress I can make. I will return to LZ32 if I dont get any where soon though
QuoteI want to have a routine that can open compressed files for textures + music etc
Given that most files are already stored in a much better compressing format (png/jpeg/wavelet for textures, mp3/ogg/aac for sound, many different approaches for meshes), there's usually not much benefit from another layer of compression.
I once used ace for archiving & linking data-archives (which gained only few percent).
So far I have only seen text compressing. every time I try to compress anything else it ends up bigger. I am using a meathod similar to LZW but without a dictionary. it uses raw uncompressed data and pointers to previous raw data. the decompressor is 32 bytes atm. Need a lot of text to make that worth while. I have seen a 256 byter that uses 8*8 texture maps they are stored as 8 bytes. I have used packed data before that was like this. I think I can use 2 bits per texel. this will still give a 1:4 size reduction and 4 colours. Havent tried sound yet, I think generating it is the best way.