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.

Before we get into putting the decoding pipeline together, I wanted to take a quick break to talk about the other asset files. Back in my first post in this series I mentioned two different graphics asset file extensions PIC and SPR (likely sprites), but so far we have only been talking about the PIC files. There may be others, but those two stood out.

Okay maybe the end of my last post was a little evil. But I swear it wasn’t just a gimmick to get you to come back and read more. I knew things weren’t perfect, and I wanted to separate out the debugging of those issues, as they are not directly related to the rendering code that was the scope of that post. So just to recap a little, we have all the pieces of the pipe built in order to be able to take a PIC file and convert it into a PPM image file. Now we can visually see the results of what is happening in the images themselves, which will hopefully make things easier to debug. So without further ado, let’s get on with the big reveal.

Or so they say. Well in this case, it may be that a picture is worth a thousand hours of looking at raw data. In my last post we decoded the RLE data stream that was output from the LZW compressed data in the PIC file. What we have now is the RAW image data, hopefully. All that is left is to render it to a screen, or some other image format that other tools can actually open. To keep things simple, the latter option is what we’re going to take. We will convert the PIC file data into a format we can open with conventional image viewing/editing tools. But before we can do that the PIC file may have one more trick up its sleeve.

In my last post we left off with having a basic LZW decompressor up and running, now it’s time for tackling the RLE_{Run-Length Encoding}encoding of the data that the LZW compressor output. This brings us one step closer to rendering the image, which at this point is becoming critical in order to see if we are on the right path in decoding the PIC file format.