(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.
Does it seem like this proposal would cover want you want in ‘more sound channels’ type features?
And does it seem like a system you’d be happy to add support for?
I’ve updated the proposal very slightly by making the Unicode strings optional, and put the result at frobnitz.co.uk/zmachine/1.2/draft2.html
I do actually like your single gestalt for all streams, but it needs to note the gestalts that are in current use even if it depreciates them at the same time. Same for stream six - it may not be needed any more, but it shouldn’t be reused.
I also agree that all new features should have gestalt checks.
I’m finding that doing this for Frotz will be fairly simple, once I get some basic threading code worked out. None of this seems workable with the DOS version. Indeed, I’ve frozen DOS Frotz’s sound capabilities at AIFF samples only. More than that is too much to ask of DOS.
So far, as far as I’m aware, no attempt to make a 1.2 Standard has been widely agreed on, and no 1.2 Standard exists.
I’m not happy with the idea of being required to document the features of every game that used non-Standard functionality, even if that functionality was documented in another New Standard proposal. If your game uses non-Standard features, that’s fine, but they’re still non-Standard.
(Obviously if the general opinion is that I’m wrong, and the Standard needs to acknowledge these other gestalt ids, I’ll add them)
I feel like I should explain my thinking behind Output Stream 5 a bit more, so someone can tell me if I missed something.
Dannii’s draft for a 1.2 standard mentions (among other things) four new features: Transcripts Protocol, @parchment opcode, Output Stream 5 (eval() stream) and Output Stream 6 (Vorple Stream).
Now, I’ll admit I haven’t looked very deeply into any of these, but:
the draft for the Transcripts Protocol states “The basic system will involve interpreters periodically sending logs of a player’s input and the story file’s responses to a web server.”
the @parchment opcode currently has only the ability to send text to be sent to eval()
Output Stream 5 also seems to be a way to output text to eval()
Output Stream 6 seems to be sending some other hints to the interpreter in text form (html or something?)
Aside from the fact that we surely don’t need two different ways to send text to one function that most interpreters won’t have access to, it seems to me that essentially all four of these operations are basically doing the same thing. That is, they are all sending textual output to the interpreter, that the interpreter may not understand, in the hope that the interpreter does understand it, and does something clever with it.
My idea is that all four of these features can be accomplished with just one output stream. Output Stream 5 therefore gives any text sent to it to the interpreter in the hopes that the interpreter knows what it is, and does something clever.
Now, obviously, the chances are fairly high that the interpreter won’t know what to do with whatever random text the game decides to spew out, but that’s okay, the interpreter is allowed to do nothing if it doesn’t understand. A slightly more difficult problem is how the interpreter can tell the difference between, say, code to be sent to eval() and nicely formatted data for the Transcripts Protocol.
And my answer is, not my problem.
My thinking is that it would be sensible for any use of output stream 5 to begin with an agreed (between game writers and interpreter writers) sequence (as for instance ‘JSEVAL:’ or ‘SCRIPTPROTOCOL:’) which lets the interpreter know what the game is expecting of it. Maybe something less ugly, but I feel it would be sensible to use meaningful words to reduce the likelyhood of two systems with different features using the same ID sequence.
But that’s up to the people implementing the features (on both the game side and the interpreter side). The Z-Machine Standard Does Not Care what is being sent to stream 5, or what is being done with it.
And then I thought, what about letting the interpreter talk back to the game? Hence Input Stream 2. I’m still less sure about Input Stream 2, though.
Yeah, a string of text where the first word is the element’s name and the rest is the class name applied to the element. It’s not pretty and I’m glad it’s gone.
Oh, this would be marvelous. I had the impression that sending meaningful data back to the game wouldn’t be possible so I have this horrible hack where the interpreter sends information through hidden commands. If using input stream 2 doesn’t break existing interpreters I’d be very interested in this option.
Well, as it stands right now, it would be an input stream like any other input stream, which means the text would be sent to @read. This means a maximum of 255 characters per call to @read, but you could call @read as many times as you want. Also all the text would be reduced to lower case. These things are why I’m not completely sure about input stream 2.
I suppose an alternative to this behaviour, maybe more useful, it to have the interpreter look at the header extension for an address, and then have a table at that address which the text is printed to when input stream 2 is active. This would allow for more text to be input with fewer operations, and preserve capitalisation. It would remove the lexical analysis that @read does, though.