As I poke at a (global style $) predicate for Dialog, my tests have produced some weird results in terms of overall screen background color (that is, the background of the parts of the screen beyond the text being printed).
The Standard doesn’t seem to say anything about this. Is there an informal/de facto standard for what causes the entire screen to change color, rather than just one line of it?
I’m currently testing in Gargoyle and ncurses Frotz.
I found this right after posting, of course:
Which explains the Gargoyle behavior. I’m not sure about Frotz though.
From Section 8:
The background color “of the lower screen” is only distinct in V6; in V5, there’s only a current background color.
Hmm, so Gargoyle is not following the spec, and Frotz…I honestly don’t know what’s going on there. I’ll tinker with that a bit more before showing my results and make sure it’s not a bug in my code.
Gargoyle is definitely buggy, it’s been reported before.
What exactly is Frotz doing?
This is my source:
(style class @fancy)
color: red;
background-color: blue;
font-style: italic;
font-weight: bold;
(program entry point)
Start (get key $)
(body style @fancy) Fancy (get key $)
(clear) Cleared fancy (get key $)
(reset body style) Reset (get key $)
(clear) Cleared reset (get key $)
Gargoyle results:
This makes sense with the knowledge that it updates the screen color on each @get_key, though it’s notable that updating the screen to a non-default color applies to previous default-colored text, but updating it to a default color does not apply to previous non-default-colored text.
(In other words, when I make the screen red-on-blue, the previous white-on-black text changes, but when I make the screen white-on-black, the previous red-on-blue text doesn’t change.)
Frotz (ncurses) results:
The third of these is the one I don’t understand. Clearing the screen filled the whole terminal with blue, which I expected. But it seems like further printing is in default white-on-black, as if clearing the screen also reset the colors.
If this is expected behavior, I can work around it in the compiler (make it output another @set_color opcode after each reset; the current colors are stored in registers). But I’m confused as to why it’s happening. I don’t think my Z-code is resetting the colors, because it doesn’t happen in Gargoyle.
Note that back when these opcodes were invented, far from all platforms could select the background colour freely per character. Typical 8-bit platforms would have the same background colour for the entire screen. This is what you get in Ozmoo as well.
I want to call this a straight-up bug in Frotz, since the spec doesn’t say that clearing the screen should reset the colors. But I guess it also doesn’t say that clearing the screen shouldn’t reset the colors…
Anyway, whether it’s a bug or not, I can work around it easily enough. Dialog’s Z-machine backend now runs another @set_color or @set_true_color after clearing the screen, and this produces the expected behavior on both Gargoyle and Frotz.
(Probably also Lectrote? I should test Lectrote.)
Somewhat recently, we discovered that one of the popular modern interpreters (Bocfel maybe?) reset the foreground colour but not the background colour, or the other way around, when performing a restart.
Oh dear…so I should make sure to set the colors to initial on initial right after startup?
In PunyInform we solved it by setting the colours to default just before @restart
That works! Now a Dialog (restart) instruction will be compiled to @set_colors 1 1; @restart rather than just @restart.
It also doesn’t say you shouldn’t fill the machine with washing-up liquid. Maybe that’s what’s wrong with it.
-Paraphrased from The Young Ones episode Nasty
Oh no, looking a bit more closely, the bit Tara quoted indicates that the background color at least needs to persist. So yeah, bug in Frotz.
(I have a lot of energy but not a lot of reading comprehension today…)
