Help with custom image format

[derboo]

I'm trying to figure out this overcomplicated image format, but I don't know what to do, anymore.

sample-1.dat, sample-2.dat are the raw binary versions of the original format
sample-1.png, sample-2.png are the same images how they appear on the screen

Big versions:

sample-1


sample-2

Every image starts with basic information. For example, here's from sample-2.dat:
8400 0000   image width (132)
2100 0000   image height (33)
0C06 0000   data block length (inverted), starting with the next following byte

Then it goes through each line from left to right like this:

0A01      one black pixel
000C 0100   ???
E1E1 E1E1   4 brown pixels
0A01      one black pixel
000B 0200   ???
E1E1      2 brown pixels
0A01      one black pixel
000B 0300   ???
E1E1 E1      3 brown pixels
0A02      two black pixels
000B 0100   ???
E1         1 brown pixel
0A06      six black pixels
000C 0100   ???
E1E1 E1E1   4 brown pixels
0A01      one black pixel
000B 0100   ???
E1         1 brown pixel
0A02      two black pixels
000C 0100   ???
E1E1 E1E1   4 brown pixels
0A01      one black pixel
000B 0100   ???
E1         1 brown pixel
0A02      two black pixels
000B 0300   ???
E1E1 E1      3 brown pixels
0A02      two black pixels
000B 0100   ???
E1         1 brown pixels
0A59      89 black pixels
000D 0C04 00   ???

Then it starts with the next line. 0F are pixels in the bright color.
I have no idea what the bits in between (with the ???) are for, but changing them apparently makes the line be shifted somewhere around the whole screen, changing many of them messes up the whole screen.

[henke37]

That smells like RLE.

[derboo]

There's no doubt about that. By now I have noticed that the mystery bytes in some way correspond to the number of brown pixels following, but why they're there when every brown block gets its own byte is beyond me.

0B01 is followed by 1 pixel
0B02 by 2
0B03 by 3

0C01 by 4
0C02 by 8
0C03 by 12
0C04 by 16
0C06 by 24

If there's 19 non-black pixels, there'l first be a block with 0B03, then a block of 0C04, probably stacking more in that manner if necessary.

0D apparently ends a line (the following pixels I posted above of course belong to the next one, then).

Hey, looks like I figured the format out! (At least how it is composed, the inclusion of the data to count the non-black pixels still seems just like a waste to me)
May 30, 2011, 09:49:03 AM - (Auto Merged - Double Posts are not allowed before 7 days.)
Hey, Tauwasser. I didn't notice I had a PM before, but it seems for some reason I can't reply directly, so I'm writing in here.

Clearing the color(?) buffer with 0A does make sense, as I totally forgot taking into account that what's black in my ripped images is actually displayed as transparence in the program (it's in DOS).

The programming seems indeed a bit shoddy. The weirdest part is, the game uses different custom formats in all kinds of places. This example is for the ending credits, the one for the opening credits was going through the image in stripes from top to bottom, skipping three columns after each one, then starting another sweep from the second column, etc.

I think I should be able now to use the collected information for a bmp-to-strangeformat converter. Thanks.