nz-lm

[nz-lm]

First Flight, 1984 (and early CGI)

Click here to watch the short on YouTube One of my favorite early CGI shorts. This was made in 1984 by Tom Bisogno and Mike Ferraro. Blue Sky Studio was in charge of the CGI for Tron, with Mike Ferraro being one of the founders. MAGI First Flight was made the same year as the MAGI demo from 1984 (don't watch if you're terrified of clowns, I guess, lots of them in early CGI demos). What's fascinating is that their software SynthaVision was originally meant to be used for radiation tracing, but it ended up developing into a sort of first version of ray-tracing. This was a point in time where no commercial animation software was available yet.

There's plenty of very interesting information about MAGI, Tron and SynthaVision in the People Behind the Pixel website! Really recommend it, it's a good read.

Begun in 1972 by Robert Goldstein and Bo Gehring, SynthaVision was the software division of MAGI that was marketed commercially for a short time under the company name of Computer Visuals Inc. The original software (Fortran2 and Fortran4 running on an IBM 360/65) used by the MAGI scientists for tracing particle radiation needed to be only slightly modified to trace light rays instead and make .. ta da!: computer graphics. (Well maybe not quite that easily.) MAGI SynthaVision - History of CG

[nz-lm]

About this blog

This blog is intended to be a place for me to write about projects I'm working on, things I found interesting, cool things I found online, or other (mostly technology) related thoughts. I think writing is a great way to digest and review things you're working on, I find it also helps me stay motivated.

A bit about me: - I'm a computer engineering student from Uruguay - C++ is my favorite programming language - I love writing and reading, as much as it seems to be a "taboo" in this field

[nz-lm]

[Random sleepless dev blog #1] Resource extracting tool for Sanitarium

I played Sanitarium last year after years of it being in my backlog of games I want to play. And I gotta say, I loved it.

If you like the type of horror that doesn't scare with jumpscares, but rather makes you uncomfortable, play it, right now.

I've been meaning to go back to digging a bit into reverse engineering and file types, so my current side project to relax is trying to uncompress all the resource files for the game, see if I find anything interesting, but I wanted the challenge of using the least amount of external resources I can. I'm nothing close to a professional in this and just writing for fun, so if you have experience doing these type of things, feel free to throw me some tips or corrections!

The Data folder for Sanitarium has the game resources separated into different RES.xxx files. For the first three of them, this is actually a split file and opening RES.001 with 7zip will get you the combined binary. Most of these files' contents are WAV files (identified by the header RIFFxxxxWAVE), then a big chunk of RES.000 contains all of the dialogues and items of the game.

Another frequent header is D3GR, which I could not find listed anywhere as a common or known file type. My only assumption would be that this is "DreamForge (3)? Graphic Resource".

Comparing different examples of this file, there's a common pattern with the first 4 bytes after the D3GR header, most times being 0x02 0x10, 0x02 0x80 and 0x02 0x00. PCX is from around that era and uses the first two bytes for information related to the version, so that could be an option. The other two bytes being either 0x00, 0x10 or 0x80, means that converted to binary only one bit is set to 1, so it could be a bit flag for something. The byte in 0x18 consistently has values from 1 to numbers under 100. Values of 1 are pretty frequent, so I suspect this is the frame count. If this is the frame count, it means that there should be a matching number of offsets.

For this specific file, the 0x18 byte is 0x0F (15 in decimal)

Starting from 0x1C, we got (hex values): 30 13, 60 26, 90 39, C0 4C, F0 5F, 20 73, 50 86, 80 99, B0 AC, E0 BF, 10 D3, 40 E6, 70 F9, A0 0C, 30 13 Which are high enough to potentially be offsets, plus, we have 15 of them. We're still missing the offset where the content starts. A big amount of file formats include that near the header, but the fact that 0x08 changed for each file didn't click for me until now. We have a variable number of headers, so clearly the size of the offset will vary as well. I've verified that moving to my current offset + 0x58 leaves me at what looks like the start of the data of the file.

So far the (probably) known part is:

The 02 could be the type of compression? From BMP file format: 0 = BI_RGB no compression 1 = BI_RLE8 8bit RLE encoding 2 = BI_RLE4 4bit RLE encoding (I'm in doubt about this)

With offsets, frame count, and (possibly) flags out of the way, we're missing other fundamental parts most image file types require:

Width?

Height? Most other bytes are set to 0, except for 0x1A which is 0x48 = 72 in decimal.

Going forward to the start of the actual data of the file, there are 4 bytes with values 0x44 0x00 0x48 0x00, these are in 0xC and 0xE. In decimal this would be 68 and 72. This pattern repeats with other files, with values that are usually around 60-170. These look like width and height values, fit for a game from this era.

We have width, height, offsets, frame count... At this point we have enough information to at least try to make a first (probably bad) version and try to check if some of these assumptions are correct. Before I write any code, I need to verify my suspicions about the offset. I manually went to the start of the data, used my hex editor to go to a specific offset, and it looks like my suspicions are correct.

0x44 and 0x48 were at the start of the first frame as well.

I'm gonna be building this with C++ as a console application, although I would like to create a basic UI and a visualizer in the future. Since I'm missing the palette I just asked Claude to generate one for me in the meantime. The objective right now is to get something, at least.

This is just a very simple console project that lets you extract both the .WAVs (much more straightforward, since all the information on the structure is available online), and the D3GR format from before.

The good news is that it works, the bad news is that it looks like garbage. At this point I need to somehow find the 256 color palette that is used in the game. I checked the headers for all the RES files but no luck. I figured the next logical step would be to open the executable with IDA and see if I could find any functions that would set the palette.

This SDL_SetPaletteColors function gets called at this section:

This part seems to be adding the contents in offset 456C80 to the stack to pass them to the function... Even better, when checking this part of the memory, I can see a char variable called OutputString with 1024 items. that's 256x4 = 1024, so definitely the palette we're looking for.

My next step is to set a breakpoint at SDL_SetSurfacePalette, and open the game

aaand... found it! there could be multiple palettes though, as it used to be common to change them (hence why this function exists).

It's looking a lot better, but some colors don't match the game (the barn is green...) so it will need a bit more work.

That will be something for another day though