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. 
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.
1 Like
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.
1 Like
David, if I were to go diving into the Journey Z6 code for something that says - insert picture file here - would you have any idea what I’m looking for please?
It’s funny because I’d dare say that I’m reasonably fluent in ZIL now, but blimey I just cannot wrap my head around pictures and sounds!!
Adam
You mean (GRAPHIC G-THING)? This is from wharf.zil.
<ROOM WHARF
(TRAVEL-COMMANDS BACK-COMMAND NUL-COMMAND NUL-COMMAND NUL-COMMAND)
(GRAPHIC G-WHARF)
(ENTER
<EXECUTE ()
<UPDATE-REMOVE ,MUD-SPELL> ;"Added 3/15"
<COND (<FSET? ,ZAN-2 ,BLACK-MIX>
<ADD-TRAVEL-COMMAND ,ZAN-2 ,INN-COMMAND>)>
<COND (<NOT <QSET? ,HERE ,SEEN>>
<TELL CR CR
"As we arrived at the waterfront, the harbormaster was just preparing to leave
his station for the evening. As we had no clear notion of which boats might be
available for charter, or what captains might be willing to take us to
the Misty Isle, we sought his advice." CR CR>
1 Like
Though that presumably just tells the SCENE routine that it needs to call the GRAPHIC routine.
And then, of course, you need to prepare the images in a way that the interpreter can understand. I made an experiment for myself once just to see if I could get anything to display at all. It was probably rubbish, and I’ve long since forgotten what I used to create a .blb file with my test images. But this is what the result looked like:
I didn’t even try to check the size of the window compared to the size of the images…
1 Like
To fill in the details: the GRAPHIC routine is defined in output.zil. It uses the SCREEN, PICINF, and DISPLAY opcodes (called @set_window, @picture_data, and @draw_picture in Inform assembly).
There seems to be code to draw a full-screen image with another image “stamped” on top of it. I don’t remember Journey well enough to say how that was used.
I could be wrong, but I get the impression that it’s used for rooms where the graphics change depending on a game event, e.g. when picking up the Nymph stone from the treasury:
<ROUTINE TREASURY-GRAPHIC ()
<SETG CURRENT-GRAPHIC <>>
<COND (<IN? ,NYMPH-STONE ,HERE>
;"Check location of stamp??"
<GRAPHIC ,G-UNDERLAND-TREASURY-NO-STONE
,G-UNDERLAND-TREASURY
,BOTTOM-RIGHT>)
(T
<GRAPHIC ,G-UNDERLAND-TREASURY-NO-STONE>)>>
Could I get that .blb file?
Sure, if you think there’s a use for it. (I had to zip it to upload it here.)
cats.blb.zip (29.3 KB)
cats.zil (298 Bytes)
I think uploads are enabled for .zblorb, just not for .blb