Attempting to convert LZW decompression code from C++ to vb.net \ VOGONS

Attempting to convert LZW decompression code from C++ to vb.net

Topic actions

Post a reply

First post, by Peter Swinkels

Posted on 2017-09-15, 20:22

Peter Swinkels Offline

Rank Oldbie

Rank: Oldbie
Posts: 541
Joined: 2005-11-16, 20:32
Location: The Netherlands

Hi,

EDIT:
After taking another look at the Github page I noticed it says that the actual algorithm for Ski or Die's *.lzw files is called "LZSS". There also appears to be a very brief/terse guide explaining the specifics of these files' formats. It can be found below the source code's directory and copy protection details.

Looking for LZW decompression code I found something that apparently can decompress files belonging to the game Ski or Die https://github.com/w4kfu/SkiOrDie. Hoping it would turn out to be compatible with the archive format I'm trying to figure out (from Cartooners which is by the same company and from the same period as Ski or Die) I tried to convert it to vb.net (Microsoft Visual Studio does support C++ but apparently not the variant required by the code I found or whatever, and while I have some knowledge about C++ I'm not very good with it.)

The vb.net conversion assumes the compressed data starts at zero based offset 0x07) (tried other offsets as well) and appears to almost work but not quite. Trying it on Shop.lzw and Splash.lzw which if these are indeed 320 x 200 x 16 color images (both files have the byte 0xA0 (160) at offset 0x05 and byte 0xC8 (200) at offset 0x06 which appear to support this assumption) should result in 160 (2 bytes per pixel for 4 bit (16) colors) x 200 = 32000 bytes of uncompressed data. Instead the results are 32444 and 31671 bytes respectively when checking the output buffer's pointer after decompression has finished. When saving what is assumed to be the decompressed pixel data and viewing it as a 160 x 200 x 256 color grey scale image the result is a nearly unrecognizable mess although you can sort of make out something that looks like a face in the case of Shop.lzw. One of the minor disadvantages of the conversion as it is now is that the output buffer's size is predetermined and there may be less or more decompressed data than it can hold.

Files:
Uncomp.zip and Shop.raw at https://drive.google.com/open?id=0BwTD43glfuu … MlR4YTJKM1RzNUk

Btw:
It would seem that the uncomp (decompression) procedure in the file uncomp.c is called from a procedure called extract in the file main.c but how the buffers are initialized or their size is determined I can't figure out.

Could anyone who knows something about C++ and perhaps LZW compression verify my code and help to get it to work properly?

Hopefully I explained things properly and thanks in advance for any help.

Last edited by Peter Swinkels on 2017-09-16, 12:58. Edited 1 time in total.

Do not read if you don't like attention seeking self-advertisements!

Did you read it anyway? Well, you can find all sorts of stuff I made using various programming languages over here:
https://github.com/peterswinkels

Reply 1 of 2, by aqrit

Posted on 2017-09-16, 12:40

aqrit Offline

Rank Member

Rank: Member
Posts: 237
Joined: 2009-06-22, 19:53

the c99 code builds okay with mingw, after commenting out the redundant strupr function.

how the buffers are initialized or their size is determined I can't figure out

1uncomp(buf, conf->map + conf->fin_size, out_buf, out_buf + uncomp_size)
2
3conf->map = entire input file read into memory (fread)
4conf->finsize = input file size
5buf =  conf->map skipping the first 4 bytes 
6out_buf = output buffer (malloc)
7uncomp_size = the first 4 bytes of the input file

Reply 2 of 2, by Peter Swinkels

Posted on 2017-09-20, 11:38

Peter Swinkels Offline

Rank Oldbie

Rank: Oldbie
Posts: 541
Joined: 2005-11-16, 20:32
Location: The Netherlands

Thanks aqrit, mingw turned out to be very useful in compiling the original code. After fine tuning my own code I got it to extract images from Ski or Die's *.lzw files. Code: https://drive.google.com/drive/folders/0BwTD4 … MlR4YTJKM1RzNUk. It turned out that the decompression algorithm itself was fine but errors in the initialization before decompression caused it to produce garbage. Now all that remains to be done is to test it on Cartooners' *.pea files.

Do not read if you don't like attention seeking self-advertisements!

Did you read it anyway? Well, you can find all sorts of stuff I made using various programming languages over here:
https://github.com/peterswinkels

Go to top of page Go to top of page

Back to Milliways

Main menu

Common searches