The first one seems eminently doable—a new builtin (unicode $) that takes a number and outputs a character. (There’s still the problem of there being more than 214 characters in Unicode, but bigger integers are a separate issue.)
The second one would mean changes to the lexer, which I have no idea how to really handle, but would only be a compiler-side change with no effect on the backend, which would be nice.
Oh, and while we’re on the topic: I would love if linking used a closure instead of a list. Currently there are two ways to do a link: (link) { Text } makes a link that says “Text” and submits “Text” when clicked, and (link [words]) { Text } makes a link that says “Text” and submits “words” when clicked. Except that the “words” here are dictionary words, which means they lose casing and spacing information. So if you click (link) {Inspector Hughes, wait}, the input is echoed as “Inspector Hughes, wait”, but if you click (link [Inspector Hughes , wait]) {tell him to wait}, the input is echoed as “inspector hughes , wait”.
I can set up an organization…something like The Ultimate Infocom Project (Still empty…). Unfortunately it seems like the link github.com/dialog is already registred so we need to come up with a new name. Any suggestions?
Perhaps using a new name would be a good idea. In terms of packaging it for distribution, there is already a name collision with the well known dialog.
That’s why I would prefer an escape sequence like \uABCD instead of a predicate. It also have the advantage of not messing with the whitespace.
Although now that I think about it, the predicate could take a dict word instead of a number: it solves the big integers issue, and makes it possible to use hexadecimal instead of decimal.
Yeah, I figured. It’s just what I feel is missing. I wasn’t expecting anyone to actually go ahead and do it.
(I could probably write a terp if I put my mind to it. Since I’m not yet where I’d like to be in terms of 68K coding, I don’t trust myself to do it right, though.)
No, that’s fine; I just overlooked that part in the manual.
Off the top of my head, the Ancient Greek ancestor of “dialog” would be transliterated as dialogos, which looks just different enough to clearly be a fork instead of the original.
Since we’re bikeshedding, I’ll suggest the name “Friends of Dialog” a la Friends of Inform 7 · GitHub - in my opinion it does a nice job of being clear without claiming ownership, and it’s a nice community precedent.
Though I guess the real debate is whether we’re forking Dialog, or just doing community maintenance on it. The IF community as a whole has previously been okay with people taking up the maintenance of projects that were abandoned, without them needing to fork them and give them new names. Dialog hasn’t been updated for as long as some of those other projects were abandoned.
Of course someone could also try emailing Linus to get his permission.
I think what would make me more likely to use Dialog for more than small projects going forward (and feel a bit better about the not-small project I’ve made in it now), would be, if not the ability to compile to Glulx, some measure of how close I am to the Z-machine/Dialog limits.
Right now, verbose compilation gives me this output:
Debug: Global registers used: 120 of 240
Debug: Properties used: 0 of 63
Debug: Flags used: 48 native, 23 extended
Which does not, to me, say “This game is right under the wire! Don’t add anything else to it!”
Could it say:
Debug: 725/750 allowed vocabulary words
Debug: 492/500 allowed objects
Or even:
Warning: 725 words for 492 objects. Adding additional objects or synonyms may trigger heap issues during disambiguation!
(Numbers are for illustrative purposes only.)
Of course, I appreciate that the runtime issues I’ve encountered may be a complex product of multiple factors that are difficult or impossible to gauge.
I don’t think there’s a hard limit on the number of dictionary words, though there is on the number of objects. Have you tried increasing the heap size?
It would be lovely if it could do this automatically, but that’s a change so fundamentally as to be effectively impossible for me.
Yes, see the bottom of this post. In my limited experience, once Dialog starts throwing heap errors, it will fill up the heap however large it is.
Default heap space (1000):
Heap space increased to 8000:
Heap increased to the maximum allowed (8192):
I’m assuming Dialog is doing something that doubles the heap each time, and is reporting on how large the heap was just before it did whatever that was.
But delete a couple of synonyms or a couple of objects and suddenly the game seems to be fine (assuming it’s not that my next couple of testers didn’t manage to hit on whichever magic word would make it crash this time).
Ah, yeah, I’m afraid I’m not familiar enough with the internals to know what exactly is going on there. The best I can recommend is to try a (trace on) right before that and see if it’s ending up in a loop somewhere, but I can’t really imagine how (collect words) would be written in a way to make that happen.
It doesn’t seem like an infinite loop, if anything there’s less trace output than for a successful command.
And when I had a more “normal” heap error (from too many per-object variables) it behaved in exactly the same way, and @improvmonster had the same experience.
But I’m not trying to hijack your thread for my issue when it has its own thread and I’ve made my peace with it anyway… Except that my wishlist for Dialog is basically that it either shouldn’t do whatever it’s doing for me or should make it clearer how I can avoid triggering it.
Looking at other Z-machine Dialog games, D’ARKUN seems to be a few KB larger than my game file. Has anyone made anything bigger than that? And my game is doing a number of weird things, but then the malleability of Dialog is what I like about it.
Oh, here’s an interesting tidbit I found in the source. The manual documents how you can use font-weight and font-style in CSS, and it’ll be translated into Z-machine “bold” and “italic” effects. But you can also use font-family: monospace; to get a monospace font. This won’t be listed in any of the diagnostic output—the compiler will tell you there’s no styling specified—but it’ll work!
Example:
(style class @fixed)
font-family: monospace;
(span @fixed) LOOK around, (span @fixed) EXAMINE something, or (span @fixed) RECALL a person.
A couple notes I work on adding color support to the Z-machine backend…
These are the different places where the compiler checks for styles:
When beginning a status area; this value is the second parameter to R_BEGIN_STATUS, but is discarded and never used by the backend
When beginning a span; this value is the first parameter to R_BEGIN_SPAN
When beginning a div; this value is the first parameter to R_BEGIN_BOX
When beginning a floating div; this value is the second parameter to R_BEGIN_BOX_LEFT and R_BEGIN_BOX_RIGHT, but is discarded and never used by the backend
These are the places where the backend uses those values:
It sets REG_STYLE to 0 at startup, then calls R_RESET_STYLE
R_ENABLE_STYLE takes a style argument and sets that style, without touching REG_STYLE (used for the (italic) etc predicates)
R_RESET_STYLE calls R_SET_STYLE with the value of REG_STYLE
R_SET_STYLE takes a style argument, disables all styles, then sets that style, without touching REG_STYLE
R_BEGIN_STATUS disables all styles, then sets reverse video style
R_END_STATUS disables all styles
R_BEGIN_BOX takes a style argument; it pushes the value of REG_STYLE, sets REG_STYLE to its argument & 0x7F, then calls R_RESET_STYLE
R_BEGIN_BOX_* (LEFT and RIGHT) take a style argument and pass it to R_BEGIN_BOX, as long as it’s not in the top status area
R_BEGIN_SPAN does the same thing as R_BEGIN_BOX
R_END_SPAN pops the stack into REG_STYLE, then calls R_RESET_STYLE
R_END_BOX does the same
R_PROGRESS_BAR clears all styles, then sets fixed-pitch, then clears all styles afterward—only if it’s not in the status bar
So if I want to add text color, I just need to use another register to hold the current color, and push and pop it alongside REG_STYLE. That’s the way to make it work with normal Dialog (span $)s.
