(Taking this to private chat)
1 Like
Flags 1 is a bit of a mess.
bit # Infocom v4 spec Infocom v5 spec Z-Machine Standard v4 Z-Machine Standard v5
0 Upper window Colors undefined Colours
1 Inverse video Display operations undefined undefined
2 Bold Bold Bold Bold
3 Italic Italic Italic Italic
4 Cursor control Monospace Monospace Monospace
5 Sound Sound undefined undefined
6 undefined undefined undefined undefined
7 undefined undefined Timed input Timed input
Infocomās v4 games all check bit 3 to test for italic, and make no other checks.
Beyond Zork tests bit 3 for italic, and bit 0 for colour. The only other Infocom v5 game which checks Flags 1 is the Solid Gold release of Zork 1, which thinks bit 3 is still the Tandy bit, and uses it to decide whether or not to advertise Zork II and Zork III when you complete the game.
Meanwhile, early versions of Inform (I think this no longer happens) use bit 1 to decide whether to display the time or the score in the statusline.
1 Like
The places where the Standard conflicts with Infocomās specs over Flags 1 are situations Infocom games never made use of. We can either fill in the undefined areas from Infocomās spec, or leave them undefined in this Standard and just note them in the Remarks.
Either way, the Standard needs to mention Informās use of bit 1 which we call, uh, game-specific (kinda like the Tandy bit).
Solid Gold Zork using the italic flag to change the ending text is just a bug, but it should be mentioned in the Remarks (interpreters may want to turn off italic support for that game, in order to get the full text).
It might be useful to clarify the expected behavior of background colors on nonstandard screen borders (i.e., the negative space around the text windows by interpreters like Gargoyle or Parchment, or screen borders such as those on the Commodore 64 - not the Version 6 window margins). This was relatively unimportant in the early days of fullscreen terps, but is now a significant player-experience consideration for some games.
Interpreter behavior is inconsistent. Parchment sets the border color on executing @erase_window 0 (CLEAR 0), effectively matching the border color to the color of the lower window. This seems like the most sensible expected behavior. Gargoyle, by contrast, does not respect the background color when executing @erase_window at all (which actually seems like a bug); instead, it sets the background color of all windows and borders to the current background color when an input opcode is executed (@read, @read_char). In practice most games with non-default background colors will both clear the screen and subsequently wait for input before changing the background color again, giving either approach similar results, but the inconsistency could cause issues for any particularly psychedelic usages of color.
Proposal: add a sentence to Ā§8.7.3.2 reading something like āFor interpreters that display additional whitespace around the game windows for layout reasons, it is recommended that erasing window 0 also set the background color of this whitespace.ā
1 Like
Appendix B says, about bit 10 of Flags 2:
Possibly set by interpreter to indicate an error with the printer during transcription
I realise that the likelihood of mentioning this here yielding any useful information is practically zero, but:
What is this? Where did it come from? What evidence was there ever for it?
Inform seems to have stopped using the bit in the header to determine statusline type as of library 6/11.
Whoops, I think thatās backwards. The release notes in 6/11 says:
- A conflict between DrawStatusLine() and DisplayStatus() on how to determine whether to display turns or time is settled in favour of checking a header flag. [L60709] (see patch note)
In 6/10, DrawStatusLine() checked (0->1)&2 whereas DisplayStatus() checked the_time.
In 6/11. they both check the global sys_statusline_flag, which is initialized as ( (HDR_TERPFLAGS->0) & 2 ) / 2. (The HDR_TERPFLAGS constant is 1.) So it is checking the header bit after all.
(Note for onlookers: In I6, (0->1) is the same as (1->0). C flashbacks, right?)
Okay, yes, after some checking, it turns out Inform is still using this header bit to this day.
Updates:
Fixed/clarified description of text-buffer in v1-v4 as per Description of read opcode for versions 1-4 Ā· Issue #76 Ā· iftechfoundation/Z-Machine-Standard Ā· GitHub
The index page now links to https://www.inform-fiction.org/zmachine/standards/current/ as the latest current version (although this doesnāt actually work yet), and the 1.0 standard has a note saying itās not the latest version.
Replaced S with Ā§ for section notation.
Added ids to all sections, so they can be linked straight to.
Merged Appendix B with Section 11, and also pulled Flags 1 and Flags 2 information out of the main header table into their own sections.
Noted Informās use of bit 1 of Flags 1 in the Remarks for section 11.
3 Likes
Iāve been thinking about some sound related issues:
What happens if you Unload a sound that is currently playing? Does it do an implicit Stop? Infocomās interpreters seem to have code to do this.
What happens if you issue a Stop command for a sound that isnāt currently playingā¦or doesnāt even exist? At first I thought the former should be an error but it wouldnāt be too difficult to set up a situation where a Stop command could succeed or fail based purely on timing, which seems wrong.
Part of the description of the opcode scan_table in section 15 says
The form is optional (and only used in Version 5?)
The Infocom zip specs confirm that while scan_table is available from version 4, the form operand is only added in version 5.
However, the table in section 14 has the form operand available from version 4, Inform will compile code using the extra operand for version 4, and Frotz recognises it in a v4 gamefile.
Should we make it definitively illegal in v4, (itās unlikely to have been used as post-Infocom v4 games are incredibly rare), or allow it, since thatās the actual implementation seems to have gone?
No strong feelings one way or the other. On one had itās nice to keep things consistent with Infocomās specs, but on the other itās apparently been de facto legal for who knows how long. Like you said, z4 is rare enough that it likely doesnāt hurt to make it illegal, but it seems someone would have to validate the existing games.
Okay, so, I did this. There is a single z4 file on the if-archive, and none of the blorb files contain z4 files. The only v4 game on the archive does not use scan_table at all.
3 Likes
Now Iām curious. Which one?
The same art show also had the only v7 game Iām aware of as an entry.
And just to be sure, Iāve gone through all the Infocom z4 files, and those that donāt just crash txd only use the three-operand scan_table.
Unless thereās any objections, Iām going to change this to make the form operand v5 and later.
2 Likes
Section 8.8.3.2 was not updated to reflect the addition of the two true_colour properties.
Current:
There are 16 properties, numbered as follows:
Correct:
There are 18 properties, numbered as follows:
There should be a note that some Infocom titles require a [More] with a pause, or else need to be patched. See this for details
1 Like