I wish, instead, that I could direct people to play Z6 games in Parchment, or in other popular interpreters based on Bocfel, including Gargoyle, Lectrote, and Spatterlight.
But Bocfel has only “partial” support for Z6, and, specially, as far as I know, it has no support for graphics.
@cas Would this be a lot of work? A little work? Is it possible in principle, given the architecture of Bocfel?
Doing Z6 games properly would be a lot of work, which is almost entirely due to the screen model.
Versions 1-5 (including 7 & 8) are “simple”, really only needing the ability to draw characters to specific locations on the screen and/or have a scrolling screen of text. Glk conveniently provides this, so Bocfel latches onto that for its drawing.
Version 6 is wildly different. It’s basically a canvas to draw on in kind-of weird ways (through “windows” which are really more like constrained viewports to the canvas rather than windows as we tend to think of them), with all sorts of operations to handle text & graphics in a different way than all other versions.
This is completely incompatible with Glk, so for Bocfel to really work with these games, it’d have to have a new UI that does all the work, meaning handling what Glk already does plus the new graphics work.
I would love to add complete support for version 6 games, but I have absolutely no time frame in mind for it. Maybe one day it’ll happen…
That being said, the next Gargoyle release will include basic graphics support for the Z-machine. It won’t do any fancy layout, but depending on the game (Journey’s right out), you can at least get a somewhat acceptable feel for its graphics.
Some examples:
Arthur (the sword in the stone is a bit out of place!)
Yeah, and that’s what I documented on IF Wiki, but I’d love to be able to point people to a “Play Online” link for these games.
It sounds to me like the easiest path from here to a web-playable Z6 interpreter would be to create an SDL Frotz web app, using Emscripten. Does that sound right?
@draw_image works (or, will work in the next release), but the coordinates are ignored. That’s because the main window is a Glk text buffer, which supports graphics, but places them at the current cursor position (not exactly true but close enough as far as the Z-machine is concerned).
PNGs in Blorb files work just fine.
The Blorb format supports a resolution chunk which allows games to specify how images ought to be scaled. This might be the best way to go, since it should allow you to scale based on the actual size of the user’s display.
I wonder if it would help to split the main screen into two Glk windows for Z6, and draw all graphics in one and all text in the other. Not ideal, certainly, but it would let you put graphics at arbitrary positions in the graphics window.
I thought about that and rejected it because, while that’d improve some graphics (e.g. those out-of-place Arthur pictures), there are other times where the text needs to be inline, e.g. the drop cap “A” at the beginning of Zork Zero.
But now that I’ve thought some more, at least for the Infocom games, it may well be possible to do a bunch of special-casing and improve the appearance, at least in some cases. Arthur, Zork Zero… though something like Shogun mixes text and graphics too much to work.
But I’ll explore this, and see how good (or bad!) it can look.
With only 4 Z6 Infocom games, and each having a finite number of images, it would be feasible to special case which ones should be inline and which should be shown in a separate graphics window. That could be a good addition to Bocfel.
But Dan’s idea of an Emscripten port of SDL Frotz might be the best way to get them to play online. It could also bundle the images all in together to remove any complications.
I wrote an interpreter in Rust that plays all zcode games including Z6. It isn’t 100% complete yet and I wasn’t planning to release it until it was (I’m kind of a perfectionist). Unfortunately I can’t work on it at the moment as I am trying to find a new job.
Truthfully the interpreter is just meant to be sort of a reference implementation. All the Z-machine behavior is actually encapsulated in a Rust library of which the interpreter is merely a front-end application for it. The front-end is split between a web assembly client and a web server back-end, allowing running of zcode games purely on the server, with the webassembly serving as the UI.
While it’s nowhere near as polished as Frotz’s proper version 6 support, I’ve had some good results with special-casing graphics in Bocfel.
Arthur doesn’t look half bad. Palette shifting isn’t implemented (and will require either a Glk extension or a custom Blorb file), and the banner staffs that flank the sides of the screen aren’t shown, since they really are meant to be used with a fixed screen size, e.g. 320x200… but it’s serviceable:
If you look carefully you’ll see jumbled text at the bottom. At the moment, a lot of F6 is needed to refresh the display because of that. If I can fix it I will, but if not, it’s more of a nuisance than anything else.
Zork Zero is just too intricate to get done in any reasonable amount of time; but I do expect that by the next Gargoyle release, at least Arthur, Journey, and Shogun should be playable.
Ok, here’s (probably) the final update before the next Gargoyle release:
I’ve got all of Infocom’s V6 games more or less supported. Zork Zero wasn’t quite as much of a challenge as I expected it to be. The experience in all games won’t be seamless, but should be good enough to play the games comfortably.
This will work with any Glk implementation that supports graphics, so won’t be limited to Gargoyle.
