It’s about time for a new Gargoyle release. If anybody is interested in doing a prerelease test, that’d be much appreciated. Thanks to the help of several contributors, we have up-to-the-minute builds available for various platforms, which allows the current development version of Gargoyle to be tested without needing to build it from source. At the moment, downloads are available for:
From an end-user perspective, there aren’t any earth-shattering changes. Some highlights:
Interpreters have been updated to the latest versions, with the exception of Geas, the Quest interpreter: it’s been removed entirely due to bugs preventing most games from being played.
The default proportional font has been switched to Charis SIL which is more consistent, visually, with the original Gargoyle font; but as always, you are free to use whatever font you’d like.
More fine-grained control over font rendering is available.
There are two tentative upcoming changes before the release, but if they can’t be resolved quickly/easily, they’re low enough priority that they won’t block the release, and will be included in a later version:
There are a few potentially useful new features in Bocfel, the Z-machine interpreter included with Gargoyle. As such these are for Z-code games only, and will not work with other game types.
A new meta-command called /notes exists which opens a text editor to allow you to take notes during your current game session. These notes are stored in save files so they will persist across saves. You can view them with /shownotes or save them with /savenotes. This is an experimental feature.
A new feature I’m referring to as “persistent transcripting” has been added. If enabled, this will automatically keep a transcript of the whole game session in memory. As with notes, transcripts are stored in save files so they will persist across saves. You can save the transcript with /savetranscript (there is no /showtranscript command as transcripts quickly get too long to conveniently view directly in the game session).
An autosave feature has been added: if enabled, games will pick up where they left off after you quit them. This requires Gargoyle to be quit via the operating system, e.g. by closing the window or ⌘Q on macOS. Issuing a QUIT command in the game will prevent an autosave from being stored. This feature is experimental and may have some odd behavior, especially with the upper window: autosave is a hack, because the Z-machine doesn’t support it directly.
2 and 3 are disabled by default. To enable them, you must edit the configuration file. On Unix (including macOS), this is one of the following:
$HOME/.config/bocfel/bocfelrc
$HOME/.bocfelrc
The former is preferred, with the latter existing only for backwards compatibility.
On Windows, it is:
%APPDATA%\Bocfel\bocfel.ini
You can find the value of %APPDATA% by opening a command shell (start → run → cmd) and typing this:
echo %APPDATA%
On my Windows 10 VM, for example, this is:
C:\Users\chris\AppData\Roaming\Bocfel\bocfel.ini
To enable persistent transcripting, add the following line:
persistent_transcript = 1
To enable autosave, add this:
autosave = 1
Some day I hope to have an easier way to do configuration, but for now, it’s all by hand.
The TADS improvements are probably good to go now (well once the PR is merged, assuming it tests properly in Garglk). We need extra improvements for Parchment, but that’s for formatting issues that don’t happen in Gargoyle.
The autosaves sounds interesting! Is it done entirely through Bocfel and not the Glk layer though, if the upper window is hacky? The way that Glulxe supports autosaves it requests the Glk layer to save its display state which might be more reliable.
It’s up to you what will or won’t block release, but I can’t recommend Gargoyle to any MacBook user without HiDPI support; it’s unacceptably blurry. IMO, all MacBook users should use Spatterlight or Lectrote instead until this bug is fixed.
That’s great news! I’ll look at getting it merged into Gargoyle.
Yes, it’s completely independent of Glk. This allows autosaves to be used regardless of which interface was used to start the game (e.g. start at home with Gargoyle, later ssh in and use a glkterm-based Bocfel to pick up where you left off).
I’m not against adding Glk-based autosaving, by any means, but I wanted a “universal” (from Bocfel’s perspective) version first, one that even works in the absence of Glk.
The HiDPI story is unfortunate for sure. I don’t own any HiDPI monitors so I’m unable to do any development on the HiDPI front. @Angstsmurf has a solid base for HiDPI work on macOS, but there are still some issues preventing it from being completely done.
A new release is really needed on the Unix side of things, due to the usage of the ancient gtk2 toolkit and SDL1 by 2019.1. As long as things haven’t regressed from 2019.1 (i.e. as long as they look equally bad there), I think the modernization of the Unix UI toolkit (and SDL version) makes a release worthwhile, from a Unix perspective (see here for the Arch Linux packager’s take).
If the next release doesn’t include HiDPI then I do think it should be the highest priority for a following release, which I’d prefer to occur sooner rather than later; but HiDPI support will rely on volunteers, so there can’t be guarantees about timeframes.
My policy with Lectrote was to assume that autosaves are invisible to the user and specific to the interpreter. If user wants to play from different machines, they can type SAVE and move the save file around.
I found a strange error running Bocfel on Windows 10. It throws up the app in the background along with the interpreter, where you can read the game. This happened on two machines. The older public build this is replacing doesn’t put the gargoyle app on the desktop. It runs with Bocfel only.
That’s effectively how Bocfel does it as well; it’s just that it’s built completely into the interpreter rather than using Glk, which has tradeoffs. It works with all Glk implementations (as well as without Glk at all), but it has to try to rebuild the state of the screen without any help from Glk. It has the same feel as Lectrote’s implementation, modulo screen repainting issues, which shouldn’t be surprising, since I was inspired to do autosave by Lectrote!
Definitely not intended; this is a side effect of Windows using CRLF for line endings. Bocfel doesn’t do any translation of the notes expressly so that it doesn’t mess up line endings when they are re-edited, but it’d be a good idea to strip CR when printing to the screen, at least. I’ve got a pull request that I’ll merge in as soon as all CI checks pass.
As a side note, there will be potential issues if you start a game on Unix and then try to edit the notes later on Windows, if you use a Windows editor that doesn’t know how to translate line endings (and vice versa). It’s no different than if you opened a Unix text file on Windows in general. I thought about storing text in a more rigid way so that line ending translation wouldn’t matter, but I found that the freedom to just use a text editor to store arbitrary text outweighed potential issues that come about from switching operating systems.
