If the upper window is 40 characters wide, and a game prints a little more, let’s say 45 characters, do all interpreters truncate the output at 40 characters, not overflowing into the next line, not causing an extra line break etc?
Have you seen an interpreter that doesn’t do this properly?
Some discussion here. Windows Frotz cuts it off, Unix Frotz corrupts the next line(!), Bocfel cuts it off, Parchment lets it word-wrap.
Even older discussion: Z-Machine undefined behavior - #7 by cas
Consensus seemed to be that clipping is correct. It’s on my list to fix for ZVM. (Parchment now uses Bocfel so will clip.)
Thanks both of you!
This means I can’t trust all terps to clip.
(This may affect a design decision in PunyInform)
That said, the Unix Frotz behavior is a bug that’s now being fixed due to that other thread, and it sounds like the Parchment behavior is being changed too.
I get that, and I’m glad the interpreters are being worked on.
PunyInform aims to make games play as well as possible across all interpreters we know of. Off the top of my head, I remember us incorporating design decisions based on bugs or peculiarites in the Gameboy interpreter, Infocom’s Apple II interpreter, Infocom’s Amiga z5 interpreter, and now this, And of course, it can compile to z3, to cater for the platforms where a z5 interpreter isn’t available.
While the modern spec doesn’t say anything explicitly about this, Infocom’s spec (p26) says:
if the program outputs characters beyond the right-hand margin [of the upper window], they are not displayed.
So perhaps this should be specified, and interpreters that don’t handle it properly will be non-compliant.
Active voice, not passive voice. :) “Perhaps we should change the spec and order non-compliant interpreters to update.”
Would this change be of sufficient benefit to be worth the effort? It sounds like it might take some constraints off PunyInform or Dialog. One of the old threads mentions My Angel but I don’t remember the circumstances of that.
Definitely not worth a spec update on its own, but there’s been talk of cleaning up some edge cases in the spec for other reasons, and I think the cost of throwing this in as well is small—now that the Unix Frotz bug is fixed, I believe all the common interpreters already do this.
The benefit to Dialog would mostly be avoiding undefined behavior when someone wants their fancy status bar to go all the way to the right edge, but I don’t think it’s really posed a problem for anyone except me. Outside of the Scott Adams translator there’s not usually a need to print full sentences of prose in the status bar.
But this also affects menus that are displayed in the upper window. I assume Dialog can do those as well. It’s pretty common that there are menu items that are too long to fit on a narrow screen. If a line spills over to the next line, menu navigation will be one line off after that point.
Right; I think if the spec defines a behavior, it should be truncating rather than wrapping (matching Infocom’s spec). It’s bad news for the Scott Adams translations, but it’s what basically all interpreters already do, and it’s better for more common uses of the upper window like menus and progress bars.