I.M.Meen (1995 PC/DOS) CMP format

[Darkfox]

Alright, thanks to Bugtest I was able to extract these files.

The images are: CMP (I thought Colormap for a moment but this seems not to be the case as they contain actual image data.)

Thanks, this is the last thing needed to be dealt with in my plans I believe. Any lossless format conversion works as I've got a tool for dealing with TGA, PCX, PNG, BMP.

[Darkfox]

Anything discernible found? I think each image has a palette since I've found no palette elsewhere.

[Darkfox]

Some of them seem compressed. Not sure exactly.

[Darkfox]

Okay, gotten a little closer, it may be a variation of BMP or PCX, not exactly sure.

[Darkfox]

Here's some stuff I've discovered, not much I know but it gives a visual aid.

[Mr.Mouse]

Making good progress there Darkfox!

[Balder]

Great progress, no doubt!

I'll try to help you with some general advise for palette image formats, as I'm a bit busy to analyze those files right now.

First of all, take (if you can) a screenshot of the game, in a lossles-compression format, like tga, being this format very simple. Then, and with the help of an hex editor, go comparing how each tga pixel is represented in the unknown format. In this process, you can find very relevant info.

Furthermore, if the format uses some kind of compression (which is very common in palette-based games from those years) there may be some special codes for doing certain operations. Maybe 0 represents filling the width*height of the image with a colour (or transparent), 128 end of a row, some codes for managing transparencies, another one for representing m-n pixels of m colour... You can imagine other codes and see them in the hex editor.

And last but not least: When you find where is the palette data stored, if you haven't done so yet, just notice that it may be not the "real" colour, but a value that has to be fixed, for example multiplying it by a constant (or any other operation). You can see this if the bytes oscillate between 0-50 or any other suspicious values.

So, if you have the right pixels but bad colour, try playing around that. In my experience, I had to multiply by 4 all values in a KB.pal palette, to get the right colour and not a messed thing like that on your image.

Nothing more, I think. I'll see that files a minute and if I find something I'll tell. As I've said, don't have much time. But keep up this, as you're very near to the solution.

Cheers!

[Balder]

Well, I took a fast look with the hex to the files, but only found a large header, with values including widht/height among other motley data.

As I previously recommended, to solve this problem it will be very handy to have the equivalent of the image already in a uncompressed format. I think the image you posted before is this one:



(Correct me if I'm wrong)

Anyway, we still need to know which of the cmp's is that image from. Maybe BOY0.CMP ?¿

Once we know, and if everything correct, we can start decoding, or at least, guessing.

See you.

[Darkfox]

Oh hey! I'll do that right now. I'll snag a screenshot of the face graphic.

[Balder]

That's great, now what image is that? I mean, what CMP does it represent, to start the investigation.

(I converted it to tga for simplicity purposes)

The first thing to do now is to search the image's widht and height in that CMP so we better understand the header.

[Darkfox]

The face to the leftt is the boy's face, BOY0.CMP, the right is the girl, GIRL0.CMP.

[Balder]

Me again!

I see we're getting somewhere. The images you attached are 56*73 (the girl one 55*73 because of the missing right line, you can see if you zoom on the image)

And the first values of the header from boy0.cmp and girl0.bmp go as this:
R...8.>.
Z...8.>.

Oka, what it means:

4 bytes -> 3674 for girl0.cmp (or 90) and 3666 for boy0.cmp (or 82). ¿Some kind of signature? In boy1.cmp is 90, again. Still investigating.
2 bytes -> It seems to be always 56. WIDTH.
2 bytes -> It seems to be always 62. HEIGHT. (But not matching with the images you attached!!!)

More interesting data I've found: Both boy0.cmp and girl0.cmp start and end with 56 zeros as this:
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Graphically, this matches as you can see a single-byte line of the same colour at the top and under the image. I think we've identified the frame!

Supposing this is correct, we also have delimited when the header ends. But this may be chance, we have to make further checks, because neither 56*73 nor 56*62 give us the number of bytes in the body. This can be because of some compression. I dunno yet.

But I think this is correct, and that we've identified how does it manage single pixels.

Anyway, with a header of 206 bytes and maybe compression this has just started. I think palette has to be placed along with the header.

I hope this will be useful, will take another look when I have time.

And as always, excuse my english. It must be very hard to read all of that! LOL How much errors per line? New record maybe? hehe

Until next time!

[Balder]

Yeah, thx for the answer, but I've already supposed so! hahahah

[Darkfox]

What do you mean?

[Balder]

Finally, structure unveiled. So this is what I mean:

unsigned long CMPSize-4
unsigned short Width
unsigned short Height
unsigned short Unknown
unsigned char Unknown
unsigned char Palette[m] (where m is 3*numberofcolours, I guess, but not yet discovered how is numberofcolours indicated)
unsigned char Pixels[n] This are the actual pixels, each byte represents a number which determines colourPosition like this: Pixel[n] * 3 + 11 (Header)

Right now I'm coding a viewer. I'll attach it when I finnish.

As you can see, there's still some gaps to fill. How is the size of the palette determined, and how does the palette exactly manage colours. I think we can fix that.

Good night!