Z-Machine 1.2 Proposal

So, yeah, I’ve put together a proposal for a new Version of the Z-Machine Standard, with some ideas of my own and some stolen/adapted from other people.

The first draft is at frobnitz.co.uk/zmachine/1.2/draft.html

Feedback would be greatly appreciated.

Och, now you’re getting into murky waters.

You’ll want to kick the old Inform (6) mailing list about this, at a minimum.

(Have not yet read document.)

I think I need to kick the Inform mailing list anyway. Inform 6 doesn’t support 1.1’s header extensions (and has no way of setting the bit required to make transparency work).

Really? I’m trying to remember if I had a patched version of Inform, or used some other method.

Well, at the least, when I tried to test transparency in Windows Frotz today, it didn’t work until I pulled out a hex editor and hacked the header extension around. If there’s a syntax to make user-defined opcodes do stuff to Flags 3, it ought to go in the 1.1 Standard. But I don’t know what it would be.

While there’s nothing per-se wrong with this, I think it has the same basic problem as the 1.1 changes - who would actually go to the trouble to write a game that would use these features? Inform 7 has increasingly made the Z-Machine irrelevant, so your audience is down to the remaining Inform 6 users, even of whom it is hard to imagine many are interested in tinkering with writing assembly to achieve these effects.

Unless a new Z-Machine spec version came up with a reasonable way of making compiling Inform 7 to Z-code practical again for even medium sized games, I think that this would be effort for little or no reward. And doing this most likely requires a 32-bit based architecture, which leaves you back at Glulx anyway.

I do know I plan to use at least two of these features (font size and sound channels) myself. The output and input streams sections are an attempt to standardise behaviour that interpreter writers are already adding in various non-standard ways.

The effort involved to update an interpreter to a minimal reading of these proposals would be almost entirely spent on making the Unicode Strings work. The other features mostly come with ways for the interpreter to be Standard while saying ‘I don’t do this’.

Obviously a Standard interpreter that implements the Standard but doesn’t actually implement the functionality of the features isn’t a lot of help to potential game writers, but my point is that the effort involved in getting this working is not that large, so I’m not sure if the potential audience for it being small matters.

Certainly the effort involved in getting the Standard out there is fairly small. If people don’t think it’s bad (in itself), then I’ve basically done all the work already.

I don’t mean to say that we should just throw the spec out there even if nobody ever implements it. That clearly is a waste of time. I merely mean that the effort involved here is even less than the fairly minimal effort required to make interpreters comply.

In general I think proposals like this (and I include my own occasional Glk/Glulx/Blorb updates) come down to: who is going to do the work? I don’t support any Z-machine interpreters, and I don’t expect to ever use these features in a game, so my opinion sort of doesn’t count.

(I might wind up implementing Inform 6 compiler options to support these features. That’s a small amount of work and I’m willing to do it if the proposal flies.)

The obvious small step here is to make every feature in 1.2 an optional feature, and add a @gestalt flag for it. (Unicode string decoding, etc.) Then an interpreter can become 1.2-compliant simply by adding the @gestalt opcode. An implementation where @gestalt always returns zero would be legal (if taciturn).

This leaves game authors in a world where they have to do a lot of explicit tests. But I guess that the typical author would only want to use a couple of these features (if any). So it’s not a big imposition.

(I have comments about other points in the proposal, but I don’t want to get down that far yet.)

I would very much welcome the ability to have more sound channels. Several of my WIPs would benefit from it.

I’ve been tinkering with the sound.h library for some time…

This is incompatible with the existing 1.2 games and stories that have been published (namely Vorple.)

What games? How is it incompatible? How have there been 1.2 games when nobody agreed on a 1.2 Standard?

Where can I find these games?

We’ve been discussing it for quite a while The last part of the discussion was whether gestalt selectors should be used to clarify holes in the spec, but now that the specs are being updated the selectors can be reduced to only new features.

Guilded Youth may be the only game published, though Gary just wrote that he is planning to publish another one by Easter. In terms of interpreters, Parchment has been supporting the existing draft spec for at least a year, probably for a couple of years (I can’t remember exactly when I added support to it.)

I did look at that thread, and the website for your 1.2 proposal. The thread didn’t seem to reach a consensus, and the specification is marked ‘Draft’, and it’s all over a year old. I didn’t realise anyone was treating it as finished.

I’m also somewhat unclear on exactly what most of the features mentioned in that draft’s gestalt list actually do, because they are defined elsewhere. A quick attempt to get an idea of them gave me the impression that four of them are different ways for the game to send text to the interpreter to make the interpreter do unusual stuff.

I don’t think we need four different ways to do that. I’m also not convinced that we have a working 1.2 Standard.

Oh, and I should mention: I’m not sure it is incompatible with the games. In this version of 1.2, Output Stream 5 sends text to the interpreter, and then the interpreter does Stuff with that text. The game can have an expectation of what the interpreter will do, but it has no actual control over what the interpreter is doing. That’s what Vorple already does, isn’t it?

I’ll also say (because apparently I like replying to myself) that the input and output streams are the bit of my proposal I’m least certain about. The general idea seems good, and it seems like there’s a demand for the functionality, but I’m not sure I’ve come up with the best way to do it.

Almost. The difference is that Vorple has more than one channel for sending text: stream 5 is for JavaScript; stream 6 is for HTML. See Vorple Core.i7x in http://vorple-if.com/vorple/build/release/i7-extensions.zip.

Stream 6 in Vorple will be removed in the next version. All HTML injections will be done with JavaScript through stream 5. Stream 6 will therefore be short-lived and probably used in one or two published games at most, and the games are bundled with a matching custom interpreter, so it’s probably safe to ignore Vorple’s stream 6 in purposes of a specification.