Things Z-machine does that Glulx does not

In it was suggested that we come up with a list of things that the Z-machine can do that Glulx cannot. I’d like to gently encourage some progress in updating the Glulx standard to eliminate these differences. I’ll start.

The way colors are handled in Glulx are very general compared to the discrete and specific commands an author can make in Z-machine. Glulx needs to be able to change fonts, colors, and backgrounds on the fly to specified colors and fonts. Glulx needs to be able to have different colors on the screen at the same time.

We went over this years ago. :confused:

I don’t want to step on debate, and I know “we talked about that in 2005” is not a very satisfying answer. But I can’t usefully revisit the inline-styles argument either.

I sketched out a forward path for Glk style control: it is posted at … :-Overview . I have not made any progress on it, because I’ve been trying to do everything else that I’ve done in being an indie developer. I know it’s not great that it’s stalled, but it is. Starting a thread here doesn’t change my life priorities.

As I said ten years ago: it is not a goal of Glulx to replicate every feature of the Z-machine. Some features are mistakes that will impede future development, accessibility, or other goals. And while “future development” may seem like a bad joke in this context, you can see why I’d rather do nothing than dedicate time on short-sighted coding.

A set of template-based web framework with I7 extensions seems (to me) a better path forward than twiddling with z-machine architecture in glulx.

For one thing I think the way save games work in Glulx is not so good. Glk is capable of implementing a “minimal YZIP screen model” (a character grid where each cell can be normal or reverse video, and there are windows which are rectangles which are subsets of the screen, and a cursor position), although you would have to implement the scrolling and scripting and so on by yourself (and maybe even make the cursor yourself too), and I don’t know if any existing YZIP story files are compatible with the minimal screen model. This does not include colours or pictures. Still, an extension to optionally support colours would help, I think (although the existing “semantic styles” of Glk is good too).

We can also add into TAVERN the proposals for various other extensions (colours, windows, sound, speech synthesis, menus, whatever). I designed that we might be able to propose such extensions easily. Whether or not a given story file is compatible with a given interpreter can be statically checked because it can read the MISC.BIN and FEATURE.SET lumps, and the ROM sizes, to determine these things. TAVERN already has “semantic styles” like Glk but the list of available styles is far smaller (normal, title, fixpitch, reverse-fixpitch), and there are no style hints (colours and other ANSI terminal stuff can be separate control codes).

Were the results of the discussion written up somewhere? That would help not have the same discussion again.

This is all open source, right? Is it possible for people to step in and help? I’m not sure if you’ve had any takers but that could help take some pressure off, I would assume. That said, it seems like it makes sense to set some ground rules because it appears there are some goals …

Is there a list of which such features are mistakes? That might help with this overall discussion. Why are those features mistakes? What makes them mistakes that would impede future development? What are possible solutions to correct the mistakes?

One of the mistakes of Z-machine I think is forced casefolding. I also think Glulx/Glk have some of their own mistakes though. But there is also some improvement, such as Glulx and Glk have extensible gestalt selectors; that still requires a runtime check though. TAVERN has the FEATURE.SET lump which allows static checking (although runtime checks are also possible).

Can we do this such that it is compatible or usable with I6?

Wish list for Christmas: Glk standard issue an immediate change to bring Z-machine more into the fold. Regardless of the fact that no interpreters support it today, the basic colors of Z-machine should have been included in the API itself. What I call “inline colors” that can be freely changed like bold and italic. Based on my many hours of coding on these features in various Glk libraries - my suggestion is to add new styles of the “legacy” z-machine colors. Which, of course, a Glulx user could redefine them and use them. But this I think would be the easiest way for the Interpreter authors to implement it… the same way they implement bold and italic. Here is a glk.h diff as example: … fac2ba40b9