Infocom's graphic format

In order to better understand Infocom’s graphic files so I can extract good data from the CGA graphic files, I’m translating pix2gif from the Ztools package from C into Perl. I seem to have it working as far as decompression. Recompression into GIF is proving harder as some of the C code doesn’t seem to translate well. To bypass that, I’ll feed the data into the PerlMagick library for further processing. Unfortunately, I cannot figure out how to get to the point where I can say “pixel x,y is color aabbcc”. If I can figure that out, I can then export the individual graphics chunks to any format I want. I used to know of a spec document on the Infocom graphic format, which should help, but I can’t find it anymore.

2 Likes

I’m really interested in this, equally interested in audio files.

Despite reading the resources available and people explaining it to me on a number of occasions - I still don’t really get it.

I think I’m too used there being a graphic file that you INSERT, and an audio file that you can start with PLAY. Something like…

<ROUTINE PLAY-SOUND ()
<PLAY “scream.wav”>
<TELL “You hear a blood curdling scream!” CR>>

1 Like

Has the CGA format been deciphered? I thought only the .MG1 files (and possibly Amiga?) had been. It would be pretty cool seeing the other pictures though. I’ve seen the black and white Macintosh ones, but never the Apple II ones.

There is some information about the original Infocom sound file formats in the IF Archive, but I’m not sure that’s what you actually meant.

My ancient port of Frotz to the Amiga supports the CGA, MCGA and Amiga versions of the graphics files released by Infocom. I’m pretty sure I didn’t do the work of decoding the formats, although where exactly the information came from I am no longer sure. Possibly an old version of Stefan Jokisch’s DOS Frotz sources.

Yeah this is the one I was thinking of, i’ve tried reading it and it just doesn’t make sense to me. I’m sure it does to others, but it just confuses me. :frowning:

I’ve managed to create a translation of the old pix2gif.c program by Mark Howell into Perl that converts into PNG. The resulting PNG files look okay, but when loaded into a Blorb file, the palettes are goofy. This goes for the MCGA graphics. For EGA graphics, the palettes are goofy AND resolution is clipped. It looks like cramming too much onto a small screen. For CGA graphics, Infocom did things in black-and-white monochrome. The color looks fine, but is also clipped as in EGA.

I suspect these problems are due to deficiencies in my pblorb code.

This is for the PC format

	+------+------+--------------------------+
	| pos  | size | contents                 |
	+======+======+==========================+
	|   0  |   2  | length of following data | prefix
	+------+------+--------------------------+
	|   2  |   1  | repeats to play          | header
	|   3  |   1  | base note                |
	|   4  |   2  | sample frequency         |
	|   6  |   2  | *** unused ***           |
	|   8  |   2  | sample data length       |
	+------+------+--------------------------+
	|  10  |   ?  | 8-bit unsigned mono data | sample data
	+------+------+--------------------------+

The prefix and header appear only once at the beginning of the file. From position 10 onward, each byte forms a single frame of 8-bit mono audio data. I suspect the confusion comes from the “base note” block and fiddling with MIDI files. I don’t understand it myself. I suspect that the MIDI mess might have inspired the now deprecated SONG format for use with Blorb.