Decompressing an Obscure Graphics Format

[ReformedJoe]

This is a pretty niche question, but hopefully someone can point me in the right direction here.

For that past while I've been poking through the files of obscure mech shooter Iron Assault.

Images are stored in a file with the extension .lz. Its not really a set format, since there are differences between certain .lz files. Some I assume contain multiple images.
Generally the files have a 4 byte header which denotes the image size, a 768 byte palette (there may be more to this section than just a palette), and then image data until the file ends (bytes as reference to the palette, stored in columns). However some files are missing the size data and the palette.

I've had some success loading background images:

(its darker than it appears in game, but I think this is just an artifact of the way I'm loading the palette)

However, when it comes to anything else it appears that the image data has been compressed. And its not something simple like RLE.
I've tried running the data naively through a lot of different compression programs with no success. Based on the age of the game, and the extension .lz I'm assuming its some form of Lempel-Ziv compression. But that's a total asspull and I have no way of knowing that for sure.

I've gone as far as to look at the games memory while running, and I can find the place where the images are apparently being decoded but this is where I run up against the limits of my knowledge.

So:
1. Does anyone have any insight into how an obscure early-mid nineties Italian dev team would have gone about compressing their image data?
failing that:
2. Does anyone have experience with reverse engineering a decompression process?

I'm all out of ideas.

[Gez]

(its darker than it appears in game, but I think this is just an artifact of the way I'm loading the palette)

That's typical of VGA palettes, they're on six bits instead of eight. (Highest channel value is 63 instead of 255.)

A simple way to display them is to multiply by four. The proper way is to bitshift them forward 2 points and backward 4 points, so that you convert 00xyztuv into xyztuvxy.

Otherwise yeah, the compressed data is most likely some custom implementation of Lempel-Ziv. I don't have the skills to help with that, though.

[ReformedJoe]

That's typical of VGA palettes, they're on six bits instead of eight. (Highest channel value is 63 instead of 255.)

Well that's good to know. Makes me wonder what other ignorant assumptions I'm making here...



I'm going to attach a representative file to this post. INTROPTR is the cursor on the main menu screen, as seen above in game.
Its a 16x16 image. Good as a test case since its one of the first things that get loaded. In case someone wants to take a peek at it and see if they have any insights.

Otherwise I'm thinking of getting DOSBox to dump whatever commands its running to a log, and seeing if I can suss out where in memory the decompression routine reside. I don't expect this to be much help since I know nothing about assembly.

As an aside this game has a really neat (cheesy) stop motion intro that you can find on youtube. Marco Spitoni, the head artist went on to work at Weta, Peter Jacksons VFX company.