Gargoyle 2023.1

I’ve just released Gargoyle 2023.1 here. Thank you to all who did prerelease testing, as it uncovered some bugs that have been squashed.

The releases page covers most new features, so some highlights here:

  • Color theme support, including system-following light/dark themes
  • Vastly improved Scott Adams interpreters (thanks to @Angstsmurf)
  • Fallback font support for missing characters, which will hopefully be the death of question marks in games with non-Latin characters
  • Bleep support on the Z-machine
22 Likes

The fallback font thing is a great relief. :)

3 Likes

Splendid news indeed. I am grateful as always for the Mojave build, thank you cas.

Thanks @cas !

I have what is probably a bit of an idiosyncratic request. I love playing IF on my kindle, and there was a fork of Gargoyle for kindle that has its last build in 2017 made by @pete330 . I think because I’m a new user the forum wont let me post links, but they made a fork on their github page with the username poker335. I’d love to use an updated build of Gargoyle on my kindle. How much work would it be to update the kindle build with the Gargoyle base changes made since 2017? How would I go about doing so?

I can’t say with certainty how much effort it’d take, given my general lack of familiarity with the Kindle port. The biggest change in Gargoye is that it no longer uses gtk2 for the UI (which the Kindle port needs). However, the UI is separated pretty cleanly from the backend, meaning that it shouldn’t be too difficult at all to sync the Kindle port with recent Gargoyle changes, just using the Kindle UI code that’s already there. There have been some changes to the UI layer’s API, meaning some work would have to be done there, but nothing major.

For somebody who has experience building with a Kindle toolchain, I think it’d be a pretty straightforward task.

The best way to do it would depend on your level of experience with development. I can give more details about what I’d expect you to need to do, if you’re looking to take on the update yourself.

Excuse my ignorance, I’m far more used to building from source on Linux.
I have an old build of Gargoyle which someone sent me, which has been linked with the standard Windows GLK libraries. How difficult would it be to build the new version for windows GLK as well? (I have both MSYS2, native Clang and Visual Studio, so there’s no shortage of C compilers on my machine.)

When you say “Windows GLK” I’m assuming you mean Gtk, since Gargoyle is a Glk implementation and has never used Windows Glk, but it did use Gtk in the past.

If that’s what you mean, it can’t be linked against Gtk anymore, since that code is gone: it uses Qt now. The older Windows Gargoyle releases were natively written for Windows, but I suppose nothing precluded anybody from building a Gtk version. Is there any particular reason you need a Gtk version?

At any rate, Gargoyle requires a POSIX environment, and the only officially-supported way to build for Windows is cross-compiling on Linux with MinGW; but only because that’s all I’ve ever tried to do. It ought to build on Windows itself just fine if you use MinGW or probably MSYS2. And actually, looking over the code, the POSIX parts are very minimal, at least in the Gargoyle core (interpreters may be another matter). It probably wouldn’t be too hard to port the POSIX bits over to Windows, if you so desired.

No, I actually mean the standard GLK library for Windows. Garglk, as a side effect of how it was designed, prints text which is unreadable via screen readers. Someone (I forget who) managed to compile Gargoyle, using the standard glk implementation for Windows, so I could actually use it instead of needing a hundred different interpreters. Unless Gargoyle has changed so much that Garglk is actually required, I figured it wouldn’t be too hard to build it using the standard Windows GLK library.

I see, you had the interpreters built against Windows Glk, as opposed to using Gargoyle’s Glk implementation.

The interpreters themselves should build against Windows Glk with little to no modification, as they are used largely unmodified by Gargoyle. I’m not sure what you had/have as a front-end launcher. Gargoyle includes a launcher that could be adapted to launch anything, but realistically I imagine a shell script/batch file would be sufficient.

In short, building Gargoyle’s interpreters against Windows Glk should be a very easy task. All you really need to do is look at terps/CMakeLists.txt to see what files and macros are needed for each interpreter, and then compile them, but point them to Windows Glk’s directory for glk.h and link against its Glk.dll.

I can’t do much for building on Windows, but it wouldn’t be a whole lot of trouble, I suspect, for me to do a cross-compile with MinGW of Gargoyle’s interpreters against Windows Glk. No launcher, I’m afraid (I don’t know Windows batch files), but I think, if you’re not able to, I could produce binaries using Windows Glk.

I honestly have no idea how CMake works. The only thing I know how to do is actually compile programs out of the box. (I know, I’m a noob.)

I overlooked one important fact: interpreters in Gargoyle are all (by default) glkunix based, which means they’re not necessarily “ready” for Windows Glk. But Bocfel (Z-machine) and Glulxe (Glulx) do have Windows Glk support. I’m attaching a build I did of these two against Windows Glk. This isn’t close to an analog of Gargoyle, as these are just two individual interpreters and no launcher, but at the very least you can use the newest versions of these interpreters with Windows Glk now.

bocfel-glulxe-winglk.zip (1.6 MB)