Small notes on Arthur behavior for interpreters

[cas (Chris Spiegel)]

While adding partial Arthur support in Bocfel, I found a couple of small things worth noting.

First, in misc.zil is the following:

<RT-CENTER-PIC ,K-PIC-SWORD>
<RT-CENTER-PIC ,K-PIC-SWORD-MERLIN>

This is from the intro, and shows the following images:

The calls are in immediate succession, but on slow machines this would “animate” Merlin appearing. However, modern systems are so fast that you never even see the first image. Bocfel sleeps for one second (by hacking in a @read_char) in between the calls, now, so that you get the animation.

Next, the adaptive palette as described by the Blorb standard isn’t sufficient to handle the palette changes required for Arthur.

Briefly, Blorb specifies that adaptive palette images should take on the palette of the last non-adaptive palette image drawn. In the case of Arthur, the decorative banner should change its appearance based on the current room image that’s drawn. But Arthur does not redraw the banner every time you change rooms. It assumes it’s still there from the last time it drew it, and just plots the new image on top, meaning it won’t change colors to the current palette.

You can see this in interpreters which follow the Blorb standard (at least Frotz and Zoom): start the game, then head east into the church. The banner stays purple. But hit F1 to redraw, and it turns brown.

I work around this in Bocfel: whenever an image is drawn, I check whether it’s a room. If so, I redraw the banner manually with the appropriate palette. Which means it has intimate knowledge of Arthur’s image needs, but that’s OK because all Infocom version 6 games require massive hackery in Bocfel, so it’s par for the course.

[Angstsmurf (Petter Sjölund)]

@cas

You can see this in interpreters which follow the Blorb standard (at least Frotz and Zoom): start the game, then head east into the church. The banner stays purple. But hit F1 to redraw, and it turns brown..

This behaviour is also present on the original Infocom Mac interpreter. In thousands of colours or millions of colours mode, the banner stays the same (purple.) If set to 256 or 16 colours, it changes whenever the room image changes. I wonder if this means Infocom never tested the game on a machine with that many colours.

EDIT: There is an equivalent behaviour in Shogun, where the side banners will change colour whenever an “inline” image is drawn, if the machine is set to 256 colours or less. When the game begins, the banners stay brown if you have more than 256 colours, otherwise they turn blue.

EDIT 2: To further complicate things, in Shogun, with the Mac set to 256 colours, the borders will change colour at the beginning of certain chapters. If you instead set the machine to 16 colours, the borders will change colour every time an illustration is drawn, just like on the Amiga. However, the borders will change to a different set of colours than on the Amiga. I guess that the Mac does some kind of proximity mapping when drawing a 256 colour image in 16 colours.

[Mike_G (Mike)]

I’m fairly sure nothing supported more than 256 colors at the time Arthur was released. If there was, it would’ve been rare.

[zarf (Andrew Plotkin)]

I believe the Mac II supported 16-bit and 32-bit color mode, but you had to buy a third-party graphics card, which were eye-wateringly expensive.

(This is surprisingly hard to get authoritative details on! I pulled out my copy of “Inside Macintosh V”, which documents the Mac II and Color Quickdraw. But it’s focused on the OS API, not what the user sees. It just explains that some video devices are “direct color” and some use “color look-up tables”, and apps have to support both.)

EDIT-ADD: “Version 1.0 of 32-Bit QuickDraw shipped in May 1989…” (Mac Tech Note QD1) So you had to have a Mac 2 and a third-party graphics card and install a system update (from a floppy! The “Mac Color Disk”.) And that was just a couple of months before Arthur shipped. So it is unlikely that Infocom would have tested that configuration.

[Mike_G (Mike)]

@zarf

I believe the Mac II supported 16-bit and 32-bit color mode, but you had to buy a third-party graphics card, which were eye-wateringly expensive.

The Mac II was hardly cheap either!

[Angstsmurf (Petter Sjölund)]

@zarf

you had to have a Mac 2 and a third-party graphics card and install a system update (from a floppy! The “Mac Color Disk”.) And that was just a couple of months before Arthur shipped.

That is a valid excuse for not catching that bug. There are other colour-related bugs (at lower colour depths) that are less understandable.

Changing the text colours with the in-game COLOR command to white on blue, and then saving, gives this:

The save dialog box leaves a darker shade of blue behind. Changing the background to red before loading this save file results in this:

Restart the game in this state, and you get this:

EDIT: These are all from SheepShaver, so it is possible that they are emulator bugs.

[jcompton]

All this Wild West of classic Mac color reminds me of the time I changed color depth while playing some strategy game (pretty sure a Chris Crawford title) and a message popped up along the lines of “You changed the color depth! You must be a software reviewer. Stuff is probably going to be broken now.”

[DavidK (David Kinder)]

Around the time of the release of these games I was playing them on an Amiga, which had a palete based hardware display model, so that if you changed the colour of palette entry 3, say, all pixels drawn with that colour would update automatically on the display, transparently to the software. This definitely caused oddities in the behaviour of some of the Infocom games.

At this distance in time, distinguishing between the intended behaviour, the actual behaviour in practice at the time and what it’s reasonable for interpreters to support is probably impossible.

[Mike_G (Mike)]

@DavidK

At this distance in time, distinguishing between the intended behaviour, the actual behaviour in practice at the time and what it’s reasonable for interpreters to support is probably impossible.

Not to mention the divergence in interpreters and even game files across platforms for V6.

Edit: The only V6 game I played back then was Zork Zero on DOS.

[cas (Chris Spiegel)]

@Angstsmurf

EDIT: These are all from SheepShaver, so it is possible that they are emulator bugs.

I see exactly the same behavior emulating Mac OS 9 on PPC with qemu, so it seems probable that it’s just buggy here.

[cas (Chris Spiegel)]

@DavidK

At this distance in time, distinguishing between the intended behaviour, the actual behaviour in practice at the time and what it’s reasonable for interpreters to support is probably impossible.

I can’t argue with that. I’m not even sure there can be a definitive intended behavior.

The box and sale sheet use the same image that is apparently from the Mac:

But that doesn’t square with the colors it should be with the adaptive palette, which is applied on the Mac as shown by Petter above. So maybe this was a screenshot from an early build?

There are several gameplay videos on YouTube:

• Apple II
• Amiga
• DOS EGA
• DOS VGA

Unsurprisingly, Apple & DOS EGA don’t do the palette shifting as described by the Blorb standard, while Amiga & DOS VGA do. If I had to hazard I guess I’d say the palette use was intentional, or at least not unwelcome, on machines that supported it.

At the very least I think it makes the case that a good effort is good enough. As with many games of the era, the varied abilities of target systems meant different graphics depending on capabilities, and there’s no harm in modern interpreter authors following that.

[Angstsmurf (Petter Sjölund)]

@cas

At the very least I think it makes the case that a good effort is good enough.

I very much agree with this.I don’t think anyone wants modern interpreters to mimic all the quirks of the original systems. For that, we have emulators.

(Counterpoint: I seem to recall there were some people here that really wanted modern Scott Adams format interpreters to mimic certain weird quirks of the originals. At least that was easy to implement.)

That said, I’m starting to obsess over exactly how the borders in Shogun change colour on the Mac, in 256-colour and 16-colour modes, respectively and compared to the Amiga.

[Angstsmurf (Petter Sjölund)]

@cas

I see exactly the same behavior emulating Mac OS 9 on PPC with qemu, so it seems probable that it’s just buggy here.

The dialog box leaving a shadow behind is the kind of thing that might be happening because we run the game under a later operating system than the one it was developed on.

[zarf (Andrew Plotkin)]

@Angstsmurf

The dialog box leaving a shadow behind is the kind of thing that might be happening because we run the game under a later operating system than the one it was developed on.

I don’t think so, in this case. I tested Arthur under System 7.0. System 6.0.5 would have been current but the infinitemac.org emulator doesn’t seem to be able to mount the Masterpieces ISO for that config, so I couldn’t test it.

But I think the color palette management was the same between 6.0.5 (with Color Quickdraw) and 7.0.

For classic MacOS, when a dialog box was closed, the underlying window had to redraw that area of its contents. (Classic MacOS assumed that the machine did not have enough memory to keep backing store for every window.) The Mac interpreter was clearly redrawing with the wrong color values.

[Mike_G (Mike)]

There’s nothing wrong with a little obsessing over minutia.