Loaded question probably: Glulx or Z-Machine

[DavidC]

@DavidK

@Eldritch Eschaton

So what about the fyrevm-web thing mentioned above? Isn’t some of this exactly what it’s doing? Or trying to do?

That’s Dave Cornelson’s project to try to do something a bit different: it uses the same underlying virtual machine architecture (Glulx) but with a different I/O layer (FyreVM instead of Glk). Glk was an attempt to define an I/O layer that would work in the desktop world as well as the web: FyreVM is an attempt to re-think the text adventure display model in terms of modern web technologies (I’m putting words in Dave’s mouth here).

I think that about sums it up perfectly. To clarify:

— fyrevm-web rethinks the text adventure display model in terms of modern web application development technologies —

The primary driving forces for my work are:

• separation of concerns: this is the idea that all systems have layers and it’s a good thing to keep those layers separate. so the process of building an interactive world and the process of interacting with said world (input and output) should be separate layers. fyrevm-web does exactly that.
• i wanted to leverage the overwhelming base of web based design and layout technologies instead of relying a locked down approach offered by glk.
• i wanted an IF engine that was a black box to potentially be used for non-IF purposes. I see many possibilities, but one that often crosses my mind in my daily role as a software architect is to use I7 and fyrevm as the foundation for a business rules engine. I haven’t test this out in any of my jobs, but it’s on my list of things to play around with…
• i wanted to expose the IF paradigm to external forces. fyrevm-web could be setup to accept external information and/or direct external information. If the UI has a section with embedded video, the player could potentially “change channels” and the UI would reflect this
• fyrevm and fyrevm-web allow anyone to make their own “interpreter”, something I am seriously drawn to as an IF author and technologist
• lastly, I wanted a platform that would support open web designs so I could implement some of my own stories…one such story, Reflections, will be released in 2017 and will have a very different user experience, something fyrevm-web will support easily (as long as you can work the HTML angle)

[DavidC]

@Eldritch Eschaton

For example, in your phrasing if “FyreVM is an attempt to re-think the text adventure display model in terms of modern web technologies”, it looks like this is something that TADS 3 tried to do with its own model of the WebUI. It sounds like there are at least two implementations of this idea to learn from, which I think would be interesting, particularly if, as you said, the previous styling system of Glk was being changed more to an HTML/CSS type approach.

All of the base IF platforms are pushing into web implementations, but you have to remember they all started as desktop platforms. These web implementations are add-ons to fairly old 90’s architectures. Even my efforts with fyrevm-web are tied to Inform 7, which could still use more separation of concerns within its own architecture (all event output should be handled centrally so it can be trapped and managed).

And IF development is very much like a herd of cats. We occasionally line up and play together, but more often than not we’re busy hiding in a box taking a nap.

[Dannii]

all event output should be handled centrally so it can be trapped and Managed

I’m starting to get there with my Glk extensions, but there’s a lot of legacy code to try to keep working. My tool of choice is now the old I6 directive Replace, so that I can intercept the Glk functions directly. (Unless you call them using the opcode that is.)

I don’t know what would need to happen for fyrevm though. It would really hurt to make a VM that had both Glk and channel IO, or as much as it can have both.

[allensocket]

David’s work is where I started early in my learning and working with it had a great influence on me. In many ways, he is doing what RemGlk is doing with existing .z and .ulx code. Stripping out all the legacy Glk colors, sound, graphics and turning every window into a stream. RemGlk even treats each window as it’s own independent input source (so it is, in a way, a bidirectional Channel for Input/Output). If you think of every Glk window as a stream, window rock 700 is audio commands, window rock 800 is phone vibration commands, window rock 900 is tilt sensor, you really then just come up with command protocols and convention for directing an orchestra. RemGlk breaks down in Glk’s concept of “waiting for input from player, one at a time”, but David has work on concurrent designs.

David’s work is to make the Interpreter (Glulx in his case) the orchestra director. The conductor is setting the timing and keeping the brass section in sync with the drums. If it’s Pink Floyd or Styx, the laser lights and video presentation youtube.com/watch?v=ZIhPdW9LgK0 It’s a remote-friendly design in that it isn’t tightly coupled as to producing the actual assets (graphics, sounds, etc). It focuses on remote communications channels and letting designers/artists do their work much more like the relationship to the orchestra conductor. At least that was my takeaway of concepts from it.

[Eldritch_Eschaton]

This discussion is more useful without me in it – – but I’m curious then:

What’s the benefit of two approaches – RemGlk vs fyrevm-web (if that’s an appropriate distinction) – rather than the coordination on one of those approaches?

Believe me, in my career I’m all for having more than one option to choose from. But it sounds like there’s some really smart people doing some really smart things – but all in different areas that are not compatible and may or may not overlap. Imagine if Inform 7 had two or three different competing versions that didn’t quite work the same. There’s a reason to specialize a bit on a platform, after experimentation has been done to determine viable and non-viable approaches.

I see things like RemGlk and fyrevm-web as platforms – with a possible ecosystem – but with different smart people working on them. I’m just wondering what would happen if those smart people combined forces on a project and took it as far as it could reasonably be taken.

Is my pointy-hat manager side coming out? It is, isn’t it? This discussion has been very enlightening so I’ll step back into the shadows now.

[allensocket]

@Eldritch Eschaton

What’s the benefit of two approaches – RemGlk vs fyrevm-web (if that’s an appropriate distinction) – rather than the coordination on one of those approaches?

My archaeology of David’s work is that he went the Skunk Works approach of an independent laboratory set up offsite. He published descriptions, extensions, and shared source code. He had an idea that not many people were interested in coding on - and he funded it and labored on it for his own projects and some third-party people did use his work and independently publish stories. He has been building his own set of experience with his ideas of shedding the old skin of Glk and the 80x25 screen model. He has been working on it for many years. It’s common for a small team like that to prototype and build things from scratch that others would not do. David could have left Inform 7 ecosystem entirely behind and went with other competing systems - I’ll speculate that he likes the Inform 6 / Inform 7 authoring tools much like I do when it comes to these choices.

Andrew Plotkin’s RemGlk is at the opposite end of the spectrum. It’s goal in life is to interface to the legacy C code and allow you to leverage (link with) established interpreters (many 10 years or older, For example, Evin Robertson’s Nitfol is from 1999 and I’m using it in my Android app work today) that are already using Glk interface. It furthers the vision of Glk…

David abandoned Glk entirely. RemGlk is a lot like the International Docking Adapter (IDA) en.wikipedia.org/wiki/Internati … ng_Adapter that allows Quixe + GlkOte in a web browser / HTML5 to interface with compiled C code interpreters through intermediate data representation (JSON). In my case, I am trying to view JSON and RemGlk as the API instead of Glk tightly coupled. I’m not using HTML or a web browser at all. I found it much easier to learn RemGlk’s JSON than working with Glk C programming directly. Both “channel” I/O via streams in their own way (if you view each Glk window in RemGlk as a stream).

[allensocket]

Further testing of the idea of promoting Z-code’s 11 colors to first class style_ in Glk has proven poor. As it would only create more conflicts in mixing bold and italic with colors. Since the Gnome Inform 7 build 6M62 IDE on Linux can’t even be consistent with Gargoyle or Frotz or Fizmo on Linux (nor is the Gnome Inform 7 IDE consistent with published Inform 7 documentation) - the problems point to a lack of published Inform 7 source code for 6M62 that demonstrated mixed bold, mixed italic, mixed colors, etc. The issue isn’t that we are in 1978 with the newly released DEC VT100 terminal and it is unable to mix italic and bold, the problem is testing and confusion! Clearly Linux has no trouble with mixing bold and italic, it’s the implementations of Glk in software. sigh. Here is source code for Inform 7 6M62 z-code / z-machine mixing of colors, fonts, languages, etc: raw.githubusercontent.com/Broad … Styles0.ni

[vaporware (Tara McGrew)]

@Dannii

Zarf has in the past allowed others to have a range of function codes and gestalt selectors to write external specifications for. So we could formally specify the additional Garglk functions. That would probably be an afternoon’s work. The trickier thing would be getting enough (or any) Glk libraries to commit to implementing them. If it would really help with your work on an Android terp for both Zcode and Glulx then I’d say that wouldn’t be a bad thing to do, even if our real future focus will be with the CSS extension. Zarf has reserved a range for me already so I could do up the spec for this.

That would be excellent.

Extending other Glk libraries to support zcolors shouldn’t be too difficult, I think. Here’s how it was added to Gargoyle in the first place: bitbucket.org/jmcgrew/zlr/commi … 3d2a728427

[allensocket]

@vaporware

Extending other Glk libraries to support zcolors shouldn’t be too difficult, I think. Here’s how it was added to Gargoyle in the first place: bitbucket.org/jmcgrew/zlr/commi … 3d2a728427

Thank you for posting this, hadn’t seen it and it provides some clarity. Let me say I understand the idea of ‘hints’ being in the name and allowing interprter apps the freedom to ignore colors if they so wish. That isn’t actually the problem! The problem is buggy implementations and inconsistencies. The most glaring inconsistency is that on Ubuntu Linux (Gnome) you have two major apps that run both Glulx and Z-code/Z-machine that do it very differently: Inform 7 6M62 Gnome IDE itself has severely broken implementation of zcolor… it does in fact attempt zcolor, but it does not do them like Linux Fizmo and Frotz does them on the same system - nor like the inform7.com website documentation example itself implies ( say " [item] ([front side of the item]/[back side of the item]): [if the item is locked][green letters]LOCKED[default letters][otherwise][red letters]UNLOCKED[default letters][end if]"; does not work correctly in the IDE interpreter)!

What struck me most is how motivated authors are to stick with Z-machine only apps. I understand the desire to play legendary Zork and other games, but in a way there has been a breakdown of motivation to tackle Glulx. And when I dug through all the code it was pretty clear to me the lacking colors support in Glulx over the years and the limitation of only User1/User2 was leading to wasted time by both software coders and story authors. This comes to me from a lot of reading of posts via search engines. And, of course, Android app source code commits/etc (as I mentioned several times, Android had a working Glulx interpreter with the most flexible of legal licensing - Incant github.com/qpliu/incant - that the community practically ignored since 2014).

My Glk “bring it into the fold” wishlist is that: Out of high regard to it’s legacy, the 11 or 13 Z-code/Z-machine colors be brought into the fold and examples given of how to implement them and a ‘reference Glk implementation’ be cited. Second, I think bold, italic, and underline all need to be distinguished from each other in Glk if an application so chooses. Yes, on a Frotz or Fizmo VT100-type ncurses approach they can choose to make [ bold == underline, underline == underline ] but on a modern complex system like Android it should be allowed that Glk is more clear that the story author requested one or the other and to distinguish them. Can we sneak in strikethrough? Third, the option on desired behavior of mixing these same attributes. If a platform has the capability of doing color, bold + italic, bold + underlined, bold + underlined + italic, color + bold + italic + underlined + strikethrough, how would Glk indicate to mix them and how should they appear (reference implementation, even if only a mock-up screen shot image or HTML page). If you listen careful, I’m not putting emphasis on a “nice to have wishlist” like font family or other things. And, implied fourth, bring the zcolor option into the fold for any other interpreter to use (Glulx, etc) beyond style_User1/style_User2. I’m really talking about basic consistency here between well-established interpreter apps multiplexing one Glk to multiple interpreters - and the Inform 7 build 6M62 Gnome IDE vs. Gargoyle on Gnome illustrates this inconsistency.

I understand that there is a desire for a CSS Glk-styles The Next Generation. But Android doesn’t know how to process CSS, and neither does ncurses. In many ways, Android’s native (first class) text output is actually very much in the spirit of the VT100 (ncurses) in that it allows you to take a string (words or prose) and apply bold + italic + foreground color + background color all on a character by-character basis! The world wrapping and justification take it all into account automatically (on hundreds of different sizes of screens with tricky issues like right to left Arabic السلام عليكم right in the same bold/italic schemes). Maybe people didn’t realize that a very modern text output system (Android) was built like that (reference: SpannableString github.com/BroadcastGames/Infor … Styles0.ni ). Thank you, and Happy New Year. May we all have a Glk integrated होली Holī-Day

P.S. This was an actual news headline of 2016: androidauthority.com/whatsap … ng-680598/ - let that sink in for someone who has worked with VT100/VT102/etc type terminals since 1978! You are looking at a system there that’s nearly identical to what Z-machine was doing! I understand the desire to go with CSS3 and HTML5 separation of concerns, but is that what you see people really doing there in that screen shot? They are encoding inline transitions - just like zcolor does. What is old has become new again

[Dannii]

Since someone has asked for the Garglk functions to be specced, I’ll do that, though I won’t push for any interpreters to implement it. Note that without edits to Garglk, even it won’t report support for them (through the gestalt function)!

Can we sneak in strikethrough?

Speccing what is already out there in the wild is one thing, but taking Glk in a new direction is another. While theoretically adding additional stylehints would not be impossible, we really should not. It hasn’t been previously requested by either story or interpreter authors, and it would add extra complexity because authors will want to be able to ask the terp which new stylehints they support. (And stylehint_distinguish is already a pretty terrible interface.)

CSS is much better, and it’s what Glk’s inventor wants. It’s extensible, very easy to implement for web based interpreters, and not impossible for others (CSS parsers are available in most languages.) If we’re going to expend considerable energy on an improvement to Glk then lets do the extensible option.

[allensocket]

@Dannii

CSS is much better, and it’s what Glk’s inventor wants. It’s extensible, very easy to implement for web based interpreters, and not impossible for others (CSS parsers are available in most languages.) If we’re going to expend considerable energy on an improvement to Glk then lets do the extensible option.

Then how come markdown on Github, WhatsApp’s method newly released in March 2016, reddit, and even this phpBB we are using right now doesn’t have you use CSS? There is inline COLOR coding right here, it isn’t obsolete in the Browser HTML5/CSS3 world. Same goes for strikethrough - has Glk entirely forgotten it’s ANSI / VT100 roots? character-oriented inline protocol over RS-232 serial!

Cascading is not trivial to implement and Android does not support it naively, nor does ANSI terminal like ncurses! “CSS parsers are available in most languages”, you think a big new can of worms isn’t going to open with C library choosing to parse CSS one way vs. Java library another? I’ve pointed out the historic Glk avoidance of zcolors that has frustrated interpreter app developers (including the Inform 7 6M62 IDE on Gnome)… what good is a standard if it doesn’t admit that it overlooked what the whole thing was modeled after - an ANSI / VT100 terminal with inline styles! You think CSS has a good history of how Mozilla Firefox interprets CSS vs. Microsoft Internet Explorer? Just because you can parse it, doesn’t mean that you have produced solid working examples of “how it should be” like zcolors had all along! And strikethrough is a perfectly reasonable request - Glk is supposed to support more than just Inform 6 and Inform 7 z-code and glulx!

Bigger picture: What’s happening here is that Parchment/Quixie/ifvms.js ZVM via GlkOte has made the choice to not implement zcolors + stylehints that were documented and now with desktops on Apple rapidly migrating to Lectrote - old interpreters are going to continue to decay and be abandoned. Since CSS is native to Quixe and has none of the problems of CSS in C, Java, Python, etc - it seems like a grand choice.

But I’m working with RemGlk - which isn’t Quixe where CSS is king. And you know what, Glk is supposed to support Hugo, and TADS, and all these other systems that also don’t use CSS. And introducting CSS isn’t going to modernize what is basically an inline ANSI / VT100 design that is still spiritually alive today in the examples I cited: phpBB, WhatsApp androidauthority.com/whatsap … ng-680598/ , Github Markdown, Reddit comments, Wiki formatting, etc. Inline styles (non cascading) didn’t die off and go away like was expected.

[vaporware (Tara McGrew)]

@Dannii

CSS is much better, and it’s what Glk’s inventor wants. It’s extensible, very easy to implement for web based interpreters, and not impossible for others (CSS parsers are available in most languages.) If we’re going to expend considerable energy on an improvement to Glk then lets do the extensible option.

Hmm. What’s the status of CSS-based styling these days? It’s a great idea, but I don’t want to make the perfect the enemy of the good.

The plan for CSS in Glk was first described about 7 years ago. Meanwhile, we’re still living in a world where even though Glk is the obvious choice for anyone developing an interpreter, it has no official support for a styling feature that’s part of most IF platform specs and most system text APIs.

I floated a different plan shortly afterward:

The primary goal is to make Glk capable of handling all the features
of the Z-machine: that is, to make it possible to write a full-
featured Z-machine interpreter using Glk as its output system without
giving up features like color. The secondary goal is to extrapolate
those features in a way that’s sensible for today’s more capable
hardware (e.g. 24-bit color rather than a palette of 12 colors).
Ideally, extensions like Basic Screen Effects will be more capable on
Glulx than on the Z-machine, not less.

There was some good discussion in that thread. One of the proposed features (line terminators) was added to Glk 0.7.1. Another (erasing previously printed text for use in line input) can be done without support from Glk, at the cost of some complexity in the interpreter. For the remaining feature, I proposed glk_set_stylehint_temp, which is basically garglk_set_zcolors generalized to apply to all style hints, so it could be used to implement @set_text_style as well.

garglk_set_zcolors is currently supported by Gargoyle and Chimara, and used by Nitfol, Bocfel, Frotz, and (sort of) ZLR. When I first hacked it in for ZLR, it took Z-machine color numbers and only supported the Z-machine’s palette. As implemented today in Gargoyle and Chimara, it has a companion function garglk_set_zcolors_stream, and it takes arbitrary 24-bit colors; now might be a good time to take that “z” out of the name.

I guess the next steps are

• write a spec
• assign gestalt and dispatch selectors
• patch Gargoyle and Chimara to support the selectors
• patch Basic Screen Effects to support color changes on Glulx (?)

[allensocket]

@vaporware

garglk_set_zcolors is currently supported by Gargoyle and Chimara, and used by Nitfol, Bocfel, Frotz, and (sort of) ZLR

Son of Hunky Punk for Android currently supports it too! This is the Google Play Store version: github.com/retrobits/son_of_hun … et_zcolors

[DavidK (David Kinder)]

@vaporware

For the remaining feature, I proposed glk_set_stylehint_temp, which is basically garglk_set_zcolors generalized to apply to all style hints, so it could be used to implement @set_text_style as well.

I would much rather see this as a proposal, rather than an ugly hack like garglk_set_zcolors() which limits you for no good reason to the Z-Machine colour set.

[allensocket]

@DavidK

@vaporware

For the remaining feature, I proposed glk_set_stylehint_temp, which is basically garglk_set_zcolors generalized to apply to all style hints, so it could be used to implement @set_text_style as well.

I would much rather see this as a proposal, rather than an ugly hack like garglk_set_zcolors() which limits you for no good reason to the Z-Machine colour set.

Who says “no good reason”? ANSI standard, a massive standard, is what it seems based on! en.wikipedia.org/wiki/ANSI_escape_code#Colors you could add Intensity to that. GlkTerm is out there and could have the new function calls added. Even Microsoft is still adding this, just now in 2016, to Windows 10: http://www.nivot.org/blog/post/2016/02/04/Windows-10-TH2-(v1511\)-Console-Host-Enhancements

[DavidK (David Kinder)]

@allensocket

Who says “no good reason”? ANSI standard, a massive standard, is what it seems based on! en.wikipedia.org/wiki/ANSI_escape_code#Colors you could add Intensity to that. GlkTerm is out there and could have the new function calls added.

If you’re going to propose adding something to Glk, the object of the exercise is surely to add something that is the most possible use to everyone. What vapourware suggested would let you set the colours to anything, not just the Z-Machine set. Why restrict the colour choices to the Z-Machine set? It’s useful for writing a Z-code interpreter, yes (though not if you wanted to include the Z-Machine 1.1 specification additions) but not if you’re writing a Glulx game and want arbitrary colours.

[allensocket]

@DavidK

@allensocket

Why restrict the colour choices to the Z-Machine set? It’s useful for writing a Z-code interpreter, yes (though not if you wanted to include the Z-Machine 1.1 specification additions) but not if you’re writing a Glulx game and want arbitrary colours.

Maybe with a selector for original ANSI 8 set (with intensity, doubled), 256, and 24-bit (yes, there are 24-bit terminals out there gist.github.com/XVilka/8346728 ) - all that is grounded in the character-oriented world that Glk has grown out of.

[vaporware (Tara McGrew)]

@DavidK

I would much rather see [glk_set_stylehint_temp] as a proposal, rather than an ugly hack like garglk_set_zcolors() which limits you for no good reason to the Z-Machine colour set.

garglk_set_zcolors doesn’t actually limit you to the Z-machine color set - it takes true color values, and the implementation of @set_colour has to map the Z-machine color numbers to RGB (example).

The original implementation of garglk_set_zcolors in my fork for Demona did have that limitation (and in fact still does), hence the name, but it seems the behavior was changed when the patch was merged upstream.

[Eldritch_Eschaton]

This has been a really interesting discussion and I’m hesitant to derail. I’ll point out something I said earlier up thread:

I guess overall it’s hard to see where Inform 7 development is really going. Clearly Glulx must be it because it’s the default choice for story format. And clearly Glulx has a better chance of keeping up with developments in Inform 7 (code constructs and whatnot). But it also seems like Glulx support is in an interesting state across the board. It’s sort of a catch-22. More people might stick with z-machine because of more options (or easier options), but Inform developers presumably want Glulx to be the future. Thus you really need more people focusing on Glulx to make that happen.

From this thread and others, I now realize that where “Inform 7 development” is going and where “Glulx development is going” are broadly separate ideas, even if interleaved by a certain necessity.

All this said, I’m still curious about these questions which I consider to be fundamental. There seems to be a certain level of intransparency in details (i.e., one example “garglk_set_colors doesn’t limit to the z-machine color set” as was possibly thought). There is certainly fragmentation of effort. It’s of course a subjective value judgment as to how effective that is, regardless of what can be done about it or whether anything should.

I’ve seen a couple of times this desire to stick with the ability to harness the past: i.e., z-code and the z-machine. But how important is that really? Loaded question! But I’m wondering how much effort is put into propping up an older standard and what it would mean if that effort was channeled into propping up the new standard? It’s not like the old stuff goes away. Existing interpreters and whatnot would still support z-machine. But the “next generation” would be focused on just that: the next generation. Which, it seems, has actually been here for quite some time, as evidenced by the work people have done.

The short story to that is it’s unclear to me how much of an albatross the z-machine and z-code is to current and future interactive fiction development. I get why its role is as it is right now. I grew up playing the Infocom games like I’m sure many here did. But I certainly don’t want to cling to that past necessarily, particularly if it’s more fruitful to diverge and focus on a new way that things could be.

[allensocket]

I think the original z-code of identified 8 colors (really ANSI set with intensity is 16) should be preserved through interpreter->glk->app via indexing. Even if the Glk library glk_ call only ends up calling a second glk_call with the translated 24-bit color - the interpreters should have the option of a “known indexed set”. The reason for this is vision impairment. And I think all interpreters (even those outside Inform 7 sourcing) can deal with these original ANSI colors as a recognizable set, identified by an index, that could be re-mapped. That’s was part of the reason I was experimenting with and originally saying make them style_ equal to established ones. making style_NUMSTYLES + 16.

The game author, writing script, could have the option to query the client and see if some request is placed to limit colors to this indexed set… and chose to use them instead of 16 million 24-bit colors. (You could go 32 bit and add alpha transparency while you are visiting the topic.) When being treated like bold, italics, underline, etc - 16 colors is a pretty rich selection for reading and highlighting content. Reference index codes; en.wikipedia.org/wiki/ANSI_escape_code#Colors

I’m not saying that 24bit or even the latest HDMI standards shouldn’t also be supported. A second function could do that, etc. What I was suggesting is a focus on these legacy ANSI colors and the concept that a client could remap them for visual impairment reasons. For example, a sophisticated interpreter app client could choose to map each of these 16 ANSI colors to a different font family for someone who is colorblind. Or even an e-ink reader that can do fonts but is otherwise black&white. With z-code/z-machine being the legacy basis for testing and demonstrating such features. Please excuse my verbosity on the topic. Thank you and Happy New Year.