I have invested some time today in understanding the RAW data files, which are image files.
Using the HEX editor
I started by taking a look at the title_s.raw file using my favourite hex editor. It became obvious very fast, that the RAW files contain raw pixel data, therefore earning their filename suffix. Now I had to find out, how the pixels are coded exactly. My Stone of Rosetta, so to speak, was a screenshot from the title screen
From this screenshot I could already derive some very important facts I could use in the next step.
Using C and SDL
Using C and SDL I quickly developed a little tool which simply
- reads in the complete file
- skips the first N bytes
- renders the following <width>*<height>*<bytes per pixel> bytes onto the buffer
My little tools allows to change <width>, <height>, <bytes per pixel>, <skip amount> and <position of color palette> live using keybord keys. Using it I approved that the file contains 320*200 pixels, each 1 byte long, coded as conventional (line-wise) raw pixel data.
Now I had to decode the palette data. Why did I guess, that there’s a palette?
- All cases, I examined yet, used palettes if the per-pixel-data had only 256 different states. Otherwise you would be forced to use only 256 color from a possible VGA color range of 262,144 (6 bit per channel).
- The red color in the top line „ECSTATICA“ has index 02, but an R-value of 255. So actually it should be 03, if the RGB-color was coded directly into the 1 byte per -pixel data and red would have been given 2 bits.
I started by guessing, that the palette started at offset 20 in the file. Why? Because that’s the biggest possible offset, assuming the palette requires 768 bytes of data (3 bytes per color). Then I looked up the palette index for the solid white in the lower line „a state of mind“ in the screenshot. It has RGB 255, 255, 255 i.e. a maximum white. The palette index is 01. And, as a matter of fact, the file contains the byte sequence „FF FF FF“ for entry 01, „FF 00 00“ for entry 02.
The unknown land between 00 and 20
Unknown remains the bytes before the palette at offset 20. We can assume, that the width and height are hidden somewhere in there.
Using my tool, I figured out the widths for all files in sub-folder „graphic“
Now I looked for those values in the respective files.
For the images in subfolder graphics, we can the respective width, listed in the table above, at byte offset 9 in the files. For the original image title_s.raw there’s an 64. That’s strange. Looking for the height value, I came to the conclusion that they use
- 2 bytes for the width at offset 9
- 1 byte for the height at offset 11
This makes sense in so far, that the height can never exceed 200 pixels (fitting into a single byte value range of 0-255).
Ecstatica scene files
Well, we managed to load simple image files from ECSTATICA so far. Of course the next thing I tried was to load a scene file from the actual game. Rejoiced too soon: Those are something else. I cannot load them using my current setup. Well, this is not surprising, after all. The scenes in ECSTATICA have to contain some kind of Z channel, to allow to decide whether a character is visible or behind an object on screen.
Decoding the scene files is dealt with in the next article.