…and try the commands therein. In particular, see the difference in the “timer” command between “echo” and “noecho” mode. Then type “terminate”, and hit some function keys, again in “echo” and “noecho” mode.
When new interpreters come out, you can test them with the same unit tests to verify they have the same behavior.
Turns out there was a bug in my glk_buffer_canon_normalize_uni() algorithm. And in the unit test (I misunderstood the Unicode spec, and then wrote the C code, the Javascript code, and the unit test all wrong in the same way).
I’ve uploaded a new, corrected unicasetest, but the interpreters are still buggy. So if you run the new test with my interpreters, you’ll see errors now.
I have a fix for Quixe, but it’s only on github right now. I’ll fix cheapglk and glkterm tomorrow. I won’t release updated interpreters right away, since I was planning to get the next small API bump out in the next few week. In the meantime, don’t copy my stupid mistakes.
What is the recommended way to deal with special keys that are not reserved by the OS, but which the library uses to provide certain functionality?
E.g. the left, right, up, down, home, end, delete are used for line editing; page up and page down are used for viewing the scrollback buffer; tab is used for changing between Glk windows awaiting input.
A conservative approach would disallow any of these as terminators, which leaves only the function keys and escape as acceptable values. I don’t know enough about the intended purpose of this feature to know if that is too narrow-minded to be of practical use for authors.
I’ve checked in fixes to the C and Javascript implementation of glk_buffer_canon_normalize_uni(). If you want to copy my implementation, please do it from the github source tree, not the released 1.0.0 libraries. This will be fixed in the releases cheapglk/glkterm 1.0.1 and Quixe 1.1.1
If you use a native OS implementation of Unicode normalization, the unicasetest test should still pass.
Good question. People should feel free to chime in on this. This feature exists basically to imitate Beyond Zork, which only used the function keys.
My choice (for my libraries and Quixe) was your conservative one: only allow Escape and the function keys (F1 to F12) as terminators.
Authors will have to describe what they want, if they want more than this. The only example I can think of is pre-empting arrow-up and arrow-down, to provide a different command alternative feature from the interpreter’s default command history. Speaking as a player, I’m not terribly fond of that sort of thing.
I’d once asked for 'terps to not echo the carriage return & line feed that occurs when the user hits the ENTER key. This is the feature that allows that? If so, do you have the game source for the echo/noecho test so I can toy with it real quick?
I kind of wish there were three border constants: DefaultBorder, NoBorder, Border. DefaultBorder would yield the old 0.7.0 behavior, NoBorder would work as in 0.7.1, and a non-zero Border flag would give the author a way to say, “I’d really like a border even though most libraries have shipped with them turned off for the last five years.”
I’ve got the code working but if I adjust the config defaults to enable borders, then every existing game will have borders between all its windows. If I leave it disabled in the config, 90% of players will never know the library supports the feature.
I would like the outcome to be that only new games that are aware of NoBorder and deliberately request a border will draw borders. I don’t see a way to accomplish that with only two constants and borders always on by default.
Zoom turns borders on by default, or did when I started using it 6 or 7 years ago. I thought it was a terribly ugly interpreter at first, because it threw these ugly borders all over my City of Secrets. It took me way too long to discover that the borders were a “feature” that I could turn off.
So, please don’t turn borders on by default in older games–a number of games use multiple windows to draw a single image, or use windows as UI subdivisions (e.g., gwindows.trenchcoatsoft.com/gwin3.htm). These games would look terrible with borders on, and the issue with players not knowing about the config is worse in this case, because players may assume that the game is supposed to look that way.
I wouldn’t worry that players are unaware of the borders feature, Ben–borders just don’t add anything at all to most games, and they can actively detract from most others. Authors have always had the option of making their own using narrow (1-3 px) graphics windows–this functionality is built into Flexible Windows, FYI–so there is good reason to believe that authors who didn’t actively include them didn’t think they really were needed.
It also used the up and down arrows to scroll the upper window and the number pad as direction short-cuts. I think some interpreters use page up / page down to emulate the up and down arrows, but that’s problematic if you support scroll-back. Currently, Nitfol requires the user to tab over to the upper window to enter the terminating characters to scroll the upper window. With the new API calls, I’ll probably additionally allow control-up and control-down to simulate up/down terminating characters.
Nitfol uses a crazy policy of displaying borders for proportional-split windows and none for fixed-split windows, with the border being an adjustable pane so the user can mess with the split percentage. This is on the theory that a game will be prepared to draw resized graphics on proportional splits but not fixed splits.
As Ben notes, some years ago I changed Windows Glk to default to “no borders”, and no-one complained. Gargoyle is no borders by default, and most of the OSX Inform 7 screenshots I’ve seen look like the interpreters is showing no borders.
I think I agree with Ben that I don’t like the fact that with Glk 0.71 the default is that all windows get borders. It would be better if the extra “borders” hints only indicate to the Glk library that the game has a specific desire for borders or for no borders, and the default is to let the library (and therefore the user choose.) Having all existing games suddenly have borders on will not look that attractive on Windows Glk, at least.
(If I’d read your spec changes more thoroughly earlier, I’d’ve noticed this sooner. D’oh…)
I’d read the spec and understood the change but hadn’t played enough Glk window using games to notice the discrepancy…
I agree the spec should be changed to either specify that if no hint is used it should be borderless, or to say that no hint = unspecified behaviour.
This feature was intended as a way for games to suppress window borders, because that’s what people have always requested.
I will make it clearer that this is a hint, and that the default (“Borders”) state is what libraries have always done. (I already say “This is a hint to the library”.)
My test case was GlkTerm, which has always had a “use borders / no borders” user-level preference, defaulting to borders-yes. For this release I upgraded that preference to “always / never / follow game hint”, defaulting to “follow game hints”. So there is no visible change to games under GlkTerm, unless either the user or the game does something non-default. That’s how I figured most libraries would go. (Obviously Zoom is the one I use most often.)
For libraries that have moved to a no-borders default already, I guess this feature is going to wind up being a no-op.
I should describe Quixe too… I ship Quixe with an HTML layout that includes window borders, but that’s really to demonstrate the layout structure rather than because it looks good. (My infamous brown borders and orange status line. Yeah, not my best web design ever.) In this setup, the NoBorders flag suppresses interwindow borders, as you’d expect.
The Quixe template that ships with I7 imitates the Parchment template, and doesn’t use any borders. In this setup, the NoBorders flag has no effect.
In the future I think better control over window layout via CSS will make this whole question moot.
OK, fair enough. I’ve added the new API features to Gargoyle. Thank you for doing the heavy lifting on the Unicode decomposition / normalization front - that saved me a considerable pile of work trying to figure out how to do it on all three platforms.
(Also thanks to vaporware, whose private API implementation of line terminators made it trivial to support the official version.)
I will hold off on a new release until 0.7.2, since that seems to be just around the corner.
Thank you zarf! I got it going in Inform 7. Transcript and quickie source follow. Note that the transcript is misleading (on purpose). I used the X and L abbreviations for EXAMINE and LOOK when I type them as a player, but they are expanded to their full names in the transcript.
There is a room. “Welcome to the echo chamber. Type ‘echoed by the story’ to hand input echoing over to the game, or ‘echoed by the library’ to restore it to normal. Currently the command line is [the command line echo mode].”
Section - extension
A Glulx command line echo mode is a kind of value. The Glulx command line echo modes are echoed by the story, echoed by the library, and always echoed per the interpreter.
To decide which Glulx command line echo mode is the command line echo mode: (- echo_mode -).
To change the/-- command line echo mode to (tr - a Glulx command line echo mode): (- set_line_echo({tr}); -).
Include (- Global echo_mode = (+ echoed by the library +); -) after “Definitions.i6t”.
Include (-
[ set_line_echo val;
if (~~(glk($0004, 17, 0))) { ! gestalt(gestalt_LineInputEcho)
echo_mode = (+ always echoed per the interpreter +);
return echo_mode; ! interpreter needs Glk version 0.7.1 or later
}
if (val == (+ always echoed per the interpreter +))
val = (+ echoed by the library +);
echo_mode = val;
glk($0150, gg_mainwin, echo_mode - 1); ! glk_set_echo_line_event
return echo_mode;
];
-).
First when play begins (this is the initialize command line echo mode rule): change the command line echo mode to echoed by the story.
Section - not for release
To say change --/the command line echo mode to (tr - a Glulx command line echo mode): change the command line echo mode to tr.
Understand “[Glulx command line echo mode]” as a mistake (“[change the command line echo mode to the Glulx command line echo mode understood]Currently the command line is [the command line echo mode].”).
Test me with “don’t use the TEST command / x me / foo / echoed by the library / x me / foo”.
Section - using it
when play begins, now the command prompt is “[bold type]'[roman type]”.
After reading a command when the player’s command includes “x”, replace the matched text with “Examine”.
After reading a command when the player’s command includes “l”, replace the matched text with “Look”.
After reading a command when the command line echo mode is echoed by the story, say "[bold type][the player’s command],’ I said, thinking[roman type][run paragraph on] ".
[First before printing a parser error when the command line echo mode is echoed by the story: say line break.]
[/code][/spoiler]
