The underlying interpreters have not changed: what is new is an update to the Glk implementation, Windows Glk. This brings support for the shiny new Glk 0.7.1 and 0.7.2 features: control over line input echoing and terminator characters; Unicode string decomposition and normalization; and access to the system’s date and time.
The changes are:
Fixed a long standing bug which led to incorrect Quetzal save files being produced when a Blorbed game file is loaded into the interpreter. The save files worked with previous versions of Windows Frotz as the bug was present in both the loading and saving logic, but such save files could not be loaded into other interpreters.
Unfortunately, fixing this bug means that loading old Windows Frotz saved files when running a Blorbed game is broken, as it is not possible to automatically detect old Windows Frotz saved files. To work around this, old saved files can be renamed to end with “.badsav”, which causes the interpreter to load them with the old, incorrect logic. The game position can then be re-saved as a correct Quetzal save file.
The get_prop_len opcode now returns 0 when its argument is 0, as required by the Z-Machine Standard Version 1.1.
Transcript files are now written out encoded as UTF-8, allowing non-ASCII characters to be represented, rather than being replaced by a question mark.
Unicode characters now appear correctly in the scrollback dialog, provided that the dialog font supports them.
Corrected a problem which could result in the options dialog using the wrong font.
One problem I am having is that Frotz does not seem to play well with large status bars. It scrolls new text beneath them, even on the opening screens. My current status bar has 8 lines (I know some will object, but I have my reasons). The first and last are blank just for formatting purposes. Still, it would be nice if it could sense where the status bar ended and start text from there.
Right now, four lines of text and three “spacer” lines are hidden beneath the status bar, for a total of seven lines that cannot be seen. Does Frotz only allow a single line for status bar? The Inform IDE and Parchment (on the web) read it fine and place all of the text below the status bar.
Is there a way to fix this? Especially if I send files (and Frotz) to “non-computer” people for them to play?
This status-line thing should only be a problem if you print text before the status window’s size is set. (The text is printed, and then the window opens up and covers it.) Unfortunately this is how the I6/I7 libraries do it.
The standard way to deal is simply to print eight (or however many) newlines before your opening text.
Actually I have several breaks (chapters if you will) where the screen gets cleared. It happens after all of them. If I add 3 or 4 [paragraph break]'s it looks good in Frotz, but crappy in the IDE and Parchment. If it was just the intro screen, it would be okay. But repeatedly as the story progresses, it just looks lame.
Is there a way to get Frotz to pause before writing the text, so the status bar has time to load after a clear screen, or at start up?
I guess I could do 40 [paragraph break]'s instead of a clear screen. But that seems awfully wasteful, and really not the answer, to what should be built into the interpreter (as it is in others). And depending on the window size it is being run in, it will probably look worse since there is no way of knowing where it will end up starting the first line.
Okay, just for grins I tried it. Yes, it does look worse. The slow scrolls… Not to mention [more] coming up a few times.
Is there another way around this? Or do I need two versions of every story… Normal, and Frotz friendly?
Maybe Frotz could load the status bar before printing the text? Just an idea.
As Zarf indicates, this is really an issue with the underlying I6/7 code, not the interpreter. The library code clears the screen in such a way that the status line is reset to zero height, and only puts it back when about to prompt the user for input: in doing so it assumes that any text that is printed to the main window will get pushed down by making the status bar bigger, but it’s not entitled to do that: the Z-Machine specification provides no promise that that will happen. This isn’t just Frotz: most (though not all) of Infocom’s original interpreters behave in the same way.
Anyway, enough of such finger pointing. The simplest way round this is to ensure that the status line height is correctly set at the start, and whenever the screen is cleared. I’ve just written and checked the following example, which works correctly for me in all interpreters I’ve tried:
[code]“Status Line Fun” by David Kinder.
Include Basic Screen Effects by Emily Short.
The Starting Point is a room.
Table of Fancy Status
left central right
“Line 1” “a” “b”
“Line 2” “a” “b”
“Line 3” “a” “b”
“Line 4” “a” “b”
“Line 5” “a” “b”
“Line 6” “a” “b”
“Line 7” “a” “b”
“Line 8” “a” “b”
Rule for constructing the status line:
fill status bar with Table of Fancy Status;
rule succeeds.
To reset the status line height:
(- VM_StatusLineHeight(8); -).
When play begins:
reset the status line height;
Clearing is an action applying to nothing.
Understand “clear” as clearing.
Carry out clearing:
clear the screen;
reset the status line height;
say “The display has been cleared.”.
[/code]
Those were the magic lines! Now it looks good everywhere. Thank you VERY much!
And I am sorry if I sounded a bit pissy before. I re-read what I wrote last night and realized it came across that way. That is not my usual style… It was late, and I was half asleep, so I didn’t proof-read before I hit submit. I usually type off the top of my head, then go back and edit. Looking back, I wish I had done this last night instead of just hitting submit and going to bed.
That’s okay, I know how annoying it can be when things don’t work quite right
I’ve also realised that my example code, though working, is a bit more complicated than needed. “Basic Screen Effects” provides “clear the screen” which clears the text and deletes the status line, but it also provides “clear only the main screen”, which leaves the status line alone, which is what you want. Using that only leaves the problem of the initial message on startup: either you can just print enough spaces, or do the following to set the status line height early enough that the initial text is not over-written.
[code]“Status Line Fun” by David Kinder.
Include Basic Screen Effects by Emily Short.
The Starting Point is a room.
Table of Fancy Status
left central right
“Line 1” “a” “b”
“Line 2” “a” “b”
“Line 3” “a” “b”
“Line 4” “a” “b”
“Line 5” “a” “b”
“Line 6” “a” “b”
“Line 7” “a” “b”
“Line 8” “a” “b”
Rule for constructing the status line:
fill status bar with Table of Fancy Status;
rule succeeds.
Clearing is an action applying to nothing.
Understand “clear” as clearing.
Carry out clearing:
clear only the main screen;
say “The display has been cleared.”.
To set the status line height to (n - a number) rows:
(- VM_StatusLineHeight({n}); -).
This is the set status line height rule:
let __n be the number of rows in the Table of Fancy Status;
set the status line height to __n rows.
The set status line height rule is listed first in the startup rulebook.[/code]
(As an aside, this trick of setting the status line early on in the startup rulebook is fine for Z-code, but will probably have bad results with Glulx. But with Glulx this whole problem goes away, since the Glulx screen model works how you want, anyway.)
I think I will play it safe, since I may need to go to Glulx as the size increases.
But I do like the idea of a variable size, instead of hard-coding ‘8’ as the size. I have the status bar routine as an extension… and it would be nice if later I wanted to use only 6 lines, I would just have to edit the table.
Is something like this possible?
To reset the status line height:
(- VM_StatusLineHeight(n); -)
let __n be the number of rows in the Table of Fancy Status.
Then for the opening screen, or full screen clears later, I just need to add the line:
reset the status line height;
I have tried hacking the two methods together myself, but can’t seem to get it right.
Most of the time I will just be clearing the main screen, but I’d like to leave the option open to do a full clear sometimes. I know, I expect a lot.
It is. The trick is that the Inform 6 code has to live in a phrase on its own. The following does this (this code omits doing anything about the initial text, just to keep it a bit smaller):[code]“Status Line Fun” by David Kinder.
Include Basic Screen Effects by Emily Short.
The Starting Point is a room.
Table of Fancy Status
left central right
“Line 1” “a” “b”
“Line 2” “a” “b”
“Line 3” “a” “b”
“Line 4” “a” “b”
“Line 5” “a” “b”
“Line 6” “a” “b”
“Line 7” “a” “b”
“Line 8” “a” “b”
Rule for constructing the status line:
fill status bar with Table of Fancy Status;
rule succeeds.
To set the status line height to (n - a number) rows:
(- VM_StatusLineHeight({n}); -).
To reset the status line height:
let __n be the number of rows in the Table of Fancy Status;
set the status line height to __n rows.
Clearing is an action applying to nothing.
Understand “clear” as clearing.
Carry out clearing:
clear the screen;
reset the status line height;
say “The display has been cleared.”.[/code]
Okay, now that makes sense. Thank you! I was trying to reduce everything to a simple expression, like it was a mathematical equation. That explains why some of my attempts would compile, but then I got an apology saying that it couldn’t continue because my use of Inform 6 code was confusing.
I really need to start looking into the Inform 6 documentation. I was planning on it, once I felt more comfortable with Inform 7. But it seems like now is a good time to start.
I’ll go even further and say the standard promises that will not happen and that any interpreter which pushes the text down when enlarging the upper window is non-standard. Note the last sentence in this excerpt from the 1.0 standard:
[b]8.6.1
The screen is divided into a lower and an upper window and at any given time one of these is selected. (Initially it is the lower window.) The game uses the set_window opcode to select one of the two. Each window has its own cursor position at which text is printed. Operations in the upper window do not move the cursor of the lower. Whenever the upper window is selected, its cursor position is reset to the top left. Selecting, or re-sizing, the upper window does not change the screen’s appearance. [/b]
Frotz does the right thing here.
Sorry about resurrecting old threads. I just discovered this forum!
Edit:
One caveat - Section 8.6.1 does refer to V3 specifically. However the sections on V4-5 don’t offer any conflicting advice.
DavidK - You mentioned that some Infocom interpreters do not behave this way. Do you know which ones? I’ve tested quite a few and have never seen one move the lower window text on a split.
I was thinking of Infocom’s Macintosh interpreters, which I recall had two separate windows: one for the main text and one for the status bar, so by definition resizing the status bar had to affect the overall display. It’s perhaps unfortunate but these days Z-code games really have to cope with both approaches to status bar resizing.
I think I remember that too, however I wonder if it was some older (V3) games that did that where the status line was really fixed and not the same as the upper window. I have Masterpieces of Infocom for Mac and was testing yesterday using Beyond Zork and Sherlock (both V5), which use a single window for output and don’t move text during a split. I’ll test some more when I get home tonight and see what I can find.
At best I think a game or library relying on text moving during a split is relying on undefined behavior. An interpreter that moves text during a split is really going against the grain as evidenced by the excerpt I mentioned before and also section 8.8.3 which pertains to V6: Subsequent movements of the window do not move what was printed and there is no sense in which characters or graphics ‘belong’ to any particular window once printed. It is interesting that the standard is silent on this issue with regard to V4-5 although I think there is circumstantial evidence to say it should be the same.
Anyway, enough of that. I have a question if you’ve got a moment and haven’t stopped reading yet…Lately I’ve been fiddling with the way my interpreter sets header flags in each zmachine version. I noticed that in V3 Frotz sets a value called OLD_SOUND_FLAG which is 0x10 in flags2, obviously for the sound capable version of The Lurking Horror. I remember reading about this flag somewhere else a long time ago, but the source escapes me. I currently set this flag in my interpreter however it bugs me that it isn’t mentioned in the standard. A few days ago I was testing the Amiga verison of The Lurking Horror (release 221 with sound) and noted that clearing this in the story file did not stop the game from making sound and a txd dump of the game doesn’t seem to reveal a place where that flag is read. Do you know where knowledge of this flag came from or any other information about it? Thanks.
Bonus question: In a hypothetical V4 game with sound, do you think it would use:
A) the old V3 flag
B) the new V5 flag
C) no flag
D) None of the above
It is briefly mentioned in the standard, in Appendix B: “Bit 4: Set in the Amiga version of The Lurking Horror so presumably to do with sound effects?” So it’s not very certain about what it means, but hazards a guess.
I’m operating on speculation only, which is not what you want, but I’d like to think it’s at least an educated guess.
At least one later Infocom game (Beyond Zork) makes use of the interpreter number to choose certain actions when it could instead check flags (see e.g. address 0xe33e in 57-871221, where it sets boldface on all interpreters but Macintosh), so Infocom was not averse to breaking the concept of platform-agnostic story files.
My guess is that the Lurking Horror’s Amiga release was similarly “special” in the sense that Infocom knew that this particular story file would run on that particular interpreter. I suspect the flag was, at least informally, added to the specification with the idea that future interpreters/stories (that were not known to be pinned to a platform) could make use of it, but V3 was at the end of its life by this point so it never went anywhere, and became a curiosity in a single story file. Why set it in TLH at all, if that’s the case? Perhaps because it’s the Right Thing™ to do, even if it’s not strictly necessary.
If this is true, it would explain why the flag is never made use of: it doesn’t need to be since the interpreter is (was!) guaranteed to support sound.
Hah, I’ll say (A) if only because I’d look for consistency with their “backport” of sound to V3.
I’d be cautious about extrapolating from V6 back to V4-5: the V6 screen model is quite different, and a real nuisance on modern systems, where thinking of the display as simply a rectangular array of pixels isn’t ideal. The standard should really also reflect reality, and the reality today is that, with both Glk-based interpreters and Javascript/browser based ones, resizing the status bar window will push the main text window down.
As cas notes, it’s alluded to in Appendix B of the specification. I have a vague recollection that this ultimately comes from disassembly of Infocom’s Amiga V3 interpreter: various Infocom interpreters contained bits of functionality that didn’t always seem to be used, and those areas were always a tricky point for the spec.
I’d suggest doing what Windows Frotz does, which is B.
I realize V6 is extremely different; It certainly has given me no shortage of headaches while designing my interpreter. I was merely pointing out that the behavior is consistent in both V3 and V6 and also Infocom V4-5 interpreters which to me is a strong indicator we shouldn’t be doing something completely different. Do you think the standard should be changed to reflect browser based interpeters? Changing this behavior in my interperter would be a very large amount of work I’d rather not think about, but would gladly do so if the standard were clarified in that direction.
Pushing the text down raises some nasty questions which probably haven’t been addressed fully. What happens if there is more text on the screen than will fit in the now smaller lower window? Is that text lost or does if reappear if I then shrink the upper window again? What if the text was actually printed in an upper window which was shrunk and then re-expanded? How might this affect V6 splits? Is this V5 specific or does it affect V4 too, despite the differences in their lower window cursor handling? Do all windows now ‘own’ text printed in them?
If I sound like a broken record, I guess it’s because I find it worrisome that z-code games have to take into account which interpreters they are likely to be played on and alter their behavior accordingly. The zmachine’s strongest attribute has always been its near universality. I think the zmachine should be pushed towards more consistent behavior by clarifying vague portions of the standard rather than spawning divergent implementations.
Hah, that sums up my dilemma nicely. From the standpoint of logical progression of zmachine features I agree with cas, but on the other hand Frotz is the de facto standard. I currently set the V3 flag, but now I’m leaning towards changing it. Maybe someone should write some V4 games which use sounds effects to force the issue.
The whole idea of “pushing down text” – and I think I was the first person to tread that territory, in post-Infocom interpreters – is based on the idea that the story window is a simple text buffer. It can be resized, and the text reflows. Resizing may be done by the user (resizing the whole game window), or as a result of the status line changing size (moving the story window’s top margin).
From this perspective, it’s not a behavior that has to be specified; it’s observing the way interpreters work. Modern OSes (meaning, 1995 and later!) have text-buffer widgets. So does HTML. You don’t want to fight those when you’re building an interpreter, you want to use them. So text gets reflowed into a smaller space, and probably there are small differences between the way that works on different platforms, but the result should be acceptable on that platform no matter what.
This leaves a side issue of whether the top printed line gets covered up by the story window. That’s unfortunate, but it’s the kind of legacy issue that can’t be eradicated except by declaring some interpreters Just Plain Wrong – this isn’t going to happen. Instead, we print some blank lines, and then both interpreter cases are handled with a minimum of pain.
(So, for the record, I don’t think the Z-spec should have the language implying that one case is right and the other is wrong.)
Your other points are interesting. I’ve been working on my zmachine library with a bunch of different goals in mind. One of them is to encapsulate as much zmachine behavior as possible while still allowing flexibility in the front end implmentation. As such I try not to lock my library into behavior not required by the standard, but one of my assumptions was that ‘windows’ only exist within the zmachine and the front end knows almost nothing about them. Instead, when text is written the zmachine specifies the region of the display it can be written to and whether or not it should scroll, be buffered, etc. This works fine as long as you assume text doesn’t ‘belong’ to any window once it is displayed, otherwise it won’t work. Maybe I should rethink it. Trying to decide what the zmachine knows and/or owns as opposed to the front end has been a huge pain.
I’d love some feedback on how to improve my library. The code is at http://grue.codeplex.com if anyone wants to look. I have a sample console app front end but the code isn’t on the site with the library. I could send it to anyone interested though.
