Can authors specify both foreground and background colours? And can UI elements inherit the specified colours (so links don’t override specified colours)? And then give an option to disable colours if the player really needs their light/dark mode preference to be followed?
The Å-machine includes a runtime for the Web. Dialog isn’t only for producing Z-machine (and maybe Glulx someday) output for an interpreter, or for making games for vintage hardware, though it’s good at both of those tasks.
2 Likes
Fair point! I’ve mostly been using it for running in the Å-machine, so I wasn’t sure
Relying on the interpreter to do the styling is also totally valid! That’s basically what anyone compiling to the Z-machine will do.
This change was prompted by two discussions on other parts of the forum:
- People saying that choice-based games (in Twine and Ink) almost always have custom styling that fits the game, but parser-based games (in Inform and Dialog) are usually released with default black-on-white text. I’ve made sure to include custom stylesheets with all my Dialog releases, but currently, doing that requires hacking the interpreter. I’ve gotten used to it, but why not make it simpler for others?
- People talking about how The Van der Nagel Papyrus makes good use of background color changes to indicate whether you’re in the normal world or an altered world. One of my WIPs involves switching back and forth between the dream world and the waking world, and background color changes seem like a good way to reflect that difference. The Z-machine (though not Glulx) can do this by default, but Dialog doesn’t expose that capability to the author.
Dialog already allows embedding CSS in your story file: that’s how all styling (like italics or fixed-pitch text) is currently handled. The one thing it doesn’t currently allow is embedding global CSS: a style class to apply to the entire game.
So that’s the capability I’m hoping to add. I want to make it easier for Dialog authors to give their games a custom, not-default-black-on-white look, whether that’s a full stylesheet for the web or alternating background colors for gameplay purposes on Z-machine.
- Both foreground and background colors: yes.
- UI elements inheriting the colors: yes if you supply a whole color scheme (with the custom properties), no if you don’t. A
color:making links indistinguishable from normal text is probably not what the author wanted. - Disabling colors at the interpreter level: not currently implemented, but would be possible to add. Basically applying
!importantto the interpreter’s default colors so they override anything the game tries to set.
1 Like
While I’m making this flurry of posts, I might as well run some things by the audience. Here are some of the pull requests currently being considered:
- SHOUT in an empty room currently says “You mumble some well-chosen words to yourself.” This PR changes SHOUT to say “You call out a few well-chosen words.” while other verbs like TALK use the original message.
- This one adds a hook for Inform-style “before/after printing the name of a thing” rules. By default, this hook is not used, and will be optimized out by the compiler.
- Spans with
display:nonehave been technically supported since 1a/01, but have always produced (consistent but) weird spacing. This PR officially deprecates them (by which I mean printing a warning if you use them, and adding a caution to the manual). If you want invisible text, use a div instead, which won’t do anything weird to the spacing.
Objections? Concerns? Let us know here!
Having ‘Shout’ as a default verb at all seems problematic. Do you really need it? I feel like either a game is going to want it, and will implement their own support for it, or a game won’t want it, and will surprise the author by having a probably-inappropriate response.
I know I7 went through and removed a bunch of those kinds of verbs a while back, and I think the library was better for it.
(Now that I’m thinking about it, what I kind of actually want is a checklist of All The Default Verbs, where I can add and remove whatever default verbs I want for a particular game. This is presumably well beyond the scope of either I7 or Dialog, though.)
the first think i do when i start a new dialog project is go in and strip out a bunch of verbs like KISS, SHOUT, SING, DANCE, etc. and there are a BUNCH of synonyms as well so i usually have to go through and prune some of those as well (the verb CROSS for instance is synonym-ed to ENTER , for some reason, which has caused me troubles in the past).
i agree, the stdlib would be better if it were tighter.
By default, SHOUT is a synonym for TALK:
(grammar [shout/yell/scream to [animate]] for [shout to $])
(unlikely [shout to $Obj])
~(animate $Obj)
~(action [shout to $] requires $ to be touched)
(perform [shout to $Obj])
(try [talk to $Obj])
(grammar [shout/yell/scream] for [shout])
(perform [shout])
To whom?
(asking for object in [shout to []])
Unlike Inform, Dialog generally assumes that authors won’t use the entire Standard Library unmodified—you’re expected to go through and strip out anything you don’t want. So I don’t mind having verbs like this the same way I’d mind in Inform.
If others disagree, though, I’m open to trimming down the Standard Library’s grammar a bit.
1 Like
i don’t mind doing my own trimming. except when i forget to do it… i really should keep my own “master” copy of stdlib. but i also like the concept of a “fresh start” every time.
Could always go oldschool and use underline… 
Also possible, if you want it! Dialog lets you apply arbitrary CSS to divs and spans, so you can make all your links have color: inherit and text-decoration: underline. But I’m trying to avoid footguns here; if you don’t explicitly set your links to inherit their color, they won’t be affected by a style on the <body>.
Has [more] become a default behaviour in dgdebug 1.0 and later? I have a test file with 339 tests, and another that spits out lots of output, and my make keeps stalling wanting more keypresses. Any objections to adding a flag to disable the behaviour, for automated builds?
While we’re at it, a single-letter synonym for --no-warn-not-topic could be handy, too. If we used -u for that, and -x for turning off more, then dgdebug -qux becomes a nice little shorthand for running the debugger for unit tests.
(Or, leave them both as long only, but add a -u and --unit-test that equates to --quit, --no-warn-not-topic, and --disable-more all in one flag.)
There’s a workaround: yes | make. But still.
An option to disable [more] shouldn’t be too hard to add. I believe the default has always been “print [more] if connected to a tty, otherwise don’t”, on the assumption that interactive debugging sessions will want to inspect all the text as it comes.
Looks like the most general way to go about it is to make an equivalent to -w that overrides the terminal’s reported height. Set to 0 or -1 to get infinite height. Feel free to open an issue for this, or I can make one at some point in the future.
That’s a fantastic idea, especially if you’re trying to support vintage hardware in 80x24, 80x25, 40x25, 40x24, 32x24, 22x23 
, or so forth.
(Another simple flag: make the debugger assume that it isn’t connected to a TTY, despite being so.)
1 Like
That part should be easy on anything Unix-based, right?
$ dgdebug whatever.dg | cat
1 Like
When someone is interactively debugging and using a feature like @replay, they may or may not want to read all of the output. If this feature gets added, can it also be implemented as a debug command so that someone can turn the paging on and off? (See Dgdebug for automation - #12 by Draconis)
That is annoyingly difficult to implement, but not for any fundamental reasons: currently, the way debugging verbs are handled prevents them from taking any parameters. Letting a debug verb take a parameter would require an annoying amount of refactoring.
A pair of debug verbs without arguments, which just turn “more” on and off, are easy. Would that work for your use case?
1 Like
On a separate note, prevtenet has very kindly provided me with a heatmap of which Z-machine instructions are executed most often in a playthrough of Miss Gosling:
- 15.6% of Z-machine cycles are spent in
R_WOULD_UNIFY, the convoluted Dialog “are these things equal” comparison. This routine exits quickly for simple values, so I suspect most of the time is spent comparing lists to determine which action rules to execute. - 9.2% in
R_TRY_ME_ELSE, part of the choice point implementation: a big unrolled loop that copies the argument registers onto the heap. - 7.2% in
R_RETRY_ME_ELSE, which does the opposite (pulling the argument registers off the heap). - 6.9% in
R_INNERLOOP, which…I don’t understand why the Z-machine spends much of any time here at all, really. I guess a lot of(fail)s pass through here before moving to their next destination? - 6.7% in
R_TRUST_ME, another big unrolled loop in the choice point implementation, pulling argument registers off the heap.
So if Z-machine performance becomes an issue, that’s where we should focus our efforts. (Though note this used a pure-ASCII version of the game, to avoid R_UNICODE skewing the results. How often that one runs is highly variable depending how many non-ZSCII characters the author uses.)
1 Like
Yes, two separate commands would be fine.
As long as the state can be set directly rather than using a single command which toggles it on and off, it should be fine.