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.