Not redrawing the status line every turn?

[code]“statline” by Andrew

include Basic Screen Effects by Emily Short.

room 1 is a room. the box is a thing in room 1.

reconstruct is a truth state that varies.

when play begins:
now reconstruct is true;

rule for constructing the status line when reconstruct is true (this is the redraw status rule):
deepen the status line to 3 rows;
say “Line 1[line break]Stuff = [list of carried things][line break]Turns = [turn count][line break]x”;
now reconstruct is false;

to rejig the status line to (depth - a number) rows:
(- VM_StatusLineHeight({depth}); -);

after taking:
now reconstruct is true;
continue the action;

test vanish with “get box/e/e/e/drop box/get box”[/code]

I’d like to use something like the code above, which seems like it should work.

I’ve tried other things like eliminating VM_ClearScreen(1); in the DeepStatus function, but something seems to be happening on a deeper level than I understand, and it’s definitely not in the extension.

Is there any way to keep the “rule for printing the status line” rule from firing and wiping out what was there?

This isn’t critical, but it generates some flicker in the Inform IDE when I try to use a more complex heading, so if there’s a way to leave the header as-is, that’d be way cool.


If the issue is just that you dislike the flicker, I think I already went through this when doing Leadlight Gamma, so before you reinvent the wheel -

There is some code built into Inform which unnecessarily resets the status line depth to 1 every turn before redrawing it. If the status line depth is set to other than 1 by the author for a turn, this can cause flicker in an interpreter, meaning that when the status line is left at a setting of greater than 1, there can be flicker every turn.

David Kinder gave me some code to eliminate the problem. I’ll paste it with the comment I have for it. Note that you probably don’t need to ‘deepen the status line to 3’ every turn as you are now, just when you actually want to change the size of the status line.

[rant][code][ The following DrawStatusLine() comes from the standard rules, but has had the initial call to set the status line depth to 1 removed. ]

Include (-
[ DrawStatusLine width posb;
@push say__p; @push say__pc;
VM_MoveCursorInStatusLine(1, 1);
if (statuswin_current) {
width = VM_ScreenWidth(); posb = width-15;
spaces width;
if (ForActivity(CONSTRUCTING_STATUS_LINE_ACT) == false) {
VM_MoveCursorInStatusLine(1, 2);
switch(metaclass(left_hand_status_line)) {
String: print (string) left_hand_status_line;
Routine: left_hand_status_line();
VM_MoveCursorInStatusLine(1, posb);
switch(metaclass(right_hand_status_line)) {
String: print (string) right_hand_status_line;
Routine: right_hand_status_line();
VM_MoveCursorInStatusLine(1, 1); VM_MainWindow();
@pull say__pc; @pull say__p;
-) before “Printing.i6t”.[/code][/rant]

The Inform IDE (and Zoom) are particularly bad about status-line redraw. Other interpreters buffer the changes and re-render the status line exactly once per input, which solves that problem.

(Although it would still be nice if Inform didn’t unnecessarily reset it every turn.)

Is there a reason to reset the status line every turn like that? Or to rephrase, is there any disadvantage to using that code to get rid of the flicker?

It’s good to know about the code, as well as that it’s likely an IDE-only problem at least for standalone interpreters. But from what I remember, the web browser version of Threediopolis went slowly because it re-did everything each turn, so it would be cool to speed that up in (hopefully) the final release.

I also feel minorly clever I can figure what the I6 code does, now that I’ve been pointed to it. So thanks, Wade, and thanks by extension to David Kinder for the original.

I guess I can even see how I could’ve maybe set the stack trace to 6 to see where the functions were going. That looks like a good exercise–I’ve put off learning about lower-level debugging in Inform, though I’ve been curious for a while.

I think the status line height is reset every turn to simplify things slightly for the user. That is, somebody could conceivably write a rule

Rule for constructing the status line when the heads-up display is on:
    deepen the status line to 3;
    [print stuff]

That works with the current library – when the HUD is turned off, the status line will be reset to a height of 1 automatically. If the library didn’t have this policy, you’d have to write a second rule to set the status line back to 1 yourself.

Might it be worth opening a Uservoice or Mantis issue for this to be taken a look at? Writing a second rule to set the status line again seems natural - you write the code to turn it on and the code to turn it off. That might be more efficient than having to dive into I6 to prevent the standard behaviour.

This might be one of those “niceties for the user” that looked like a very good idea at the time but which turns out to make it unnecessarily difficult for more advanced users, which you don’t notice until a later date.