We last left off having uncovered a dew more mysteries of the MicroProse PIC file format. We wrote a tool to examine PIC files to try and determine which version of the file they were, after some rework, we were fairly successful. Though in that process we uncovered a few new sub-variations in the data that we need to account for. In this post we will deal with those variations we discovered with the PIC⁹⁰ version.

Several posts back we looked at some other MicroProse titles and discovered that the PIC file format has evolved over the years with various titles. In this post we’re going to look at a few more titles that I found to have PIC files and see where they fit into the mix. Then we will hopefully be able to write some quick code to be able to identify what type of PIC file we’re looking at. This is a first stage to opening the newer variants up to our encoder/decoder.

We have some unfinished business to do in light of the discoveries we made last time. I now no longer trust my prior results with the RLE encoder, so we need to go back and revisit that result. Last post we wrapped things up by solving the red herring of the LZW compressor generating garbage. Which brings into question the issue we had surrounding the same file for RLE encoding. But first, we need to put all the pieces of the encoder together, and with that perhaps we can kill two birds with one stone. We can address the questionable RLE result, and we can fully validate our encode and decode stacks.

I may or may not have rage quit at the end of the last post. I had spent so much time debugging and getting it working only to have this one file break everything… again! It was late, I was tired, I was frustrated, and I was already past my self imposed deadline to wrap up for my blog post. I needed to walk away and get some rest and come back with fresh eyes. So here I am 12 hours later, after finally publishing my last post, let’s see if we can get to the bottom of what’s going on with the troublesome PIC file.

In my last post we took the first steps towards writing an PIC encoder by implementing the necessary pixel packing and RLE encoding schemes. All that is left is writing the LZW compressor, and that is the subject for this post. While I had hoped that by the end of this post we will have all the parts necessary to make a fully functional encoder for MicroProse PIC files., the Fates had another path in mind…

So far we’ve been focusing on decoding and rendering a PIC⁸⁸ image from F15-SE2 into something standard tools can open, and we’ve accomplished that fairly successfully I think. Now it’s time to turn things around and start writing a PIC encoder, so that we can take a custom image and turn it into a PIC file the game can open. This post will focus on the pixel packing and RLE encoding, and the next one will be on the LZW compression.

In my last post we solved the last secret of the PIC file format we have been looking at. But the image itself contains one more secret… the colour palette. Unlike more recent incarnations of the PIC file format, which have a companion PAL file, the PIC⁸⁸ version used by F19 and F15-SE2 does not. In this post we will endeavour to locate the custom palette utilized by the game.

So far we’ve managed to make great progress in being able to fully decode the PIC image into a raw image that we can then save to whatever format that we like. There is one last part of the PIC format that remains unexplained/unexplored, and that is the ‘Format Identifier’ byte that is at the very start of the file. In this post we are going to investigate that, in a rather inquisitive manner…

Now that we have our decoding of the PIC images up to a well-defined point for F15-SE2, it’s time to look and see where else MicroProse has used this format. As we know from the DarkLands document we discovered back on my second post, along with the thread on a Civilization forum, we know that the format was used in those games, albeit in a different form. Lets dig through the archives to see what other titles use the format, and if that format is the same.