need info on LZ32.DLL

[rain_storm]

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.

[stormbringer]

MSDN: http://msdn.microsoft.com/en-us/library/aa365224(VS.85).aspx

[rain_storm]

Thanks stormbringer but I already have this information. There are more functions that I cannot find at msdn. Here is the functions in LZ32-

Code: [Select]

CopyLZFile, GetExpandedName, LZClose, LZCloseFile, LZCopy, LZCreateFileW, LZDone, LZInit, LZOpenFile, LZOpenFileW, LZRead, LZSeek, LZStart
at msdn I can find only information about these functions -

Code: [Select]

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

[stormbringer]

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..

[rain_storm]

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

[Jim]

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. 

Jim

[rain_storm]

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.

[stormbringer]

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

[rain_storm]

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 -

Code: [Select]

   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

[hellfire]

I 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).

[rain_storm]

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.