It has been too long since I’ve made a release of Unix Frotz. Here it is.
Summary of changes between Frotz 2.54 and Frotz 2.55:
Frotz 2.55 was released on Saturday February 1, 2025.
This is a minor release focusing on minor enhancements and bug fixes.
NEW FEATURES
Updated and cleaned up random.inf, which is now the “Z-machine
Randomization Test Suite”.
Updated and cleaned up manual pages.
Added -L option to xfrotz - supply a Quetzal file to load on command line.
Added support for the Z-Machine Standard 1.1 save-restore prompt option.
BUG FIXES
Attempting to write a string that straddles the Z-machine’s 64k
boundary caused a segfault within Frotz itself. Frotz now will detect
this and throw a fatal error instead.
Fixed an oversight in which files created by Frotz aren’t given appropriate
filename extensions.
Fixed a stray $ that breaks the frotz filename when specifying LDFLAGS.
Updated the fix for Beyond Zork’s rotating mirror bug by now correctly
detecting attempts to address an invalid object.
Fixed brain-dead handling of undo slots.
Fixed a segfault when xfrotz detects a fatal error.
Fixed compile failure of the SDL interface for GCC 12 and maybe GCC 11.
Not a bug in Frotz itself, but the BUGS text file was deleted from the
source repository and tarball before the release of Frotz 2.50.
Fixed faulty handling of text styles in dumb interface.
Awesome! This is going to make testing Dialog much easier.
Another feature that would be quite useful for automated testing, though I’m not sure how much work it would be: a command-line option to echo input would make it a lot easier to run test scripts. Right now, running dfrotz whatever.z8 <whatever.in >whatever.out only gives me the game’s output, not the inputs that produced it, which makes it a lot harder to tell where something went off the rails. (“Okay, the diff goes haywire on this turn…but what input made it do that?”)
I’m currently working around this with a tiny Python script:
from sys import argv, stdin
import subprocess as sp
from time import sleep
proc = sp.Popen(argv[1:], stdin=sp.PIPE, text=True, bufsize=1)
for line in stdin:
print(line[:-1], end='', flush=True)
proc.stdin.write(line)
proc.stdin.flush()
sleep(0.01)
In other words, this runs through the lines of its stdin; for each one, it prints it, feeds it to dfrotz, then waits 0.01 seconds before doing the next one. But this is concerningly fragile. In past projects, I’ve made a special test build of my game that echoes the input for me; but it would be really nice to be able to do this sort of testing on arbitrary Z-code files, without needing to specifically add that feature to each one.
That’s up to the distro maintainers (see e.g. here), but usually you shouldn’t expect to see an update to a new upstream version like this without upgrading to a new version of the distribution.
Certainly that’s the case for Debian/Ubuntu-based distros; Debian has just (in the past hours) taken this update (see their tracker), but it won’t be available to a stable Debian installation before Debian 13 (trixie) is released, which I don’t expect before the second half of 2025.
Similarly, it’s likely to make its way from there to Ubuntu, but not before the 25.04 release (the Plucky Puffin).
If you want it quickly, you’ll probably need to install it manually.
How about if I add a flag for starting a transcript as soon as the game starts up? Please check out the script-from-start branch at https://gitlab.com/DavidGriffith/frotz and tell me what you think.
That would work great! Let me try building this and see if I run into any issues.
The one issue I can see is that it would strip out all formatting, but for testing formatting, I’m planning to use other interpreters instead; the point of dfrotz is to make it easy to work with the raw text.
I can confirm this. I don’t know why it’s doing that since I explicitly specified that the sf_defines.h target must be completed before moving on to compilation. If you invoke make -j again, the build finishes. Interesting enough, adding a number to the -j flag results in the build finishing without a problem.
[edit]
I see what I did wrong. The fix is to edit src/sdl/Makefile and change the line
With this new release, it seems that dumbfrotz now displays a status line before each input. This is definitely an improvement, testing-wise, but it also breaks a lot of existing test suites that expected only the raw game output.
Is there a way to disable the status line/upper window on the interpreter side?
(The transcript-from-start fix should obviate this for the main Dialog test suite, but we also have some older tests like the full-game Miss Gosling run that are expecting the raw screen output.)
I’m not sure what’s going on with the status line. On raw game output, I tried to get the dumb interface to put formatting codes into the transcript, but nothing I tried worked. I’ll look again at how the player’s commands are processed so they’ll appear in standard output.