I am especially interested in ADRIFT and was happy to see that for ADRIFT 4 games now both graphics and sound works in Gargoyle, at least on Windows (I tested with Ghost Town briefly by Finn Rosenløv) - great work
Also, it is good to hear you are looking into Adrift 5 support, which I regard as more important for the Adrift community, as almost all new Adrift games are made with Adrift 5. I have often thought about proposing to have a text only version of Frankendrift embedded in Gargoyle and Parchment but perhaps some Adrift users would be disappointed as they like to add graphics and sound to their games. However, if the alternative is no Adrift 5 support, I think text only would still be very valuable and in most cases the game would be playable without graphics, sound and map.
Just curious, I have no understanding of the technical details: Is there any chance that Gargoyle will ever run in a browser, similar to Parchment?
Good news! The next Gargoyle release will have Adrift 5 support. I’ve fixed up the build of Frankendrift on all major operating systems, and barring any weird issues that crop up, everything should be good.
Just curious, I have no understanding of the technical details: Is there any chance that Gargoyle will ever run in a browser, similar to Parchment?
If you mean something like Gargoyle, looking like it does, but in a web browser… tentatively no, although since Gargoyle uses Qt, and Qt has Qt for WebAssembly, it’s at least within the realm of possibility that somebody could try building it that way. But Frankendrift specifically might pose problems. I’m really not familiar with WASM at all, but Frankendrift is done differently than all other interpreters in Gargoyle: it has to dynamically load the Gargoyle shared library at runtime. I have absolutely no idea how that works in WASM, but I guarantee it’s more work than the other interpreters.
If somebody did go to the effort of getting Gargoyle to work in a browser, I’d happily take patches that didn’t break other stuff, but it’s not something that I will be undertaking myself. But in the end I’d just recommend Parchment!
What’s makes you interested in the idea of a web version of Gargoyle? Are there particular interpreters you want that Parchment doesn’t support yet?
I would still like to bring Frankendrift to the web. I’m not sure if dotnet have solved the issues involved in getting their async code working on the web yet.
My main interest is Frankendrift but I was curious if in the future the web is just another platform Gargoyle could be published for. No need for installing is a big plus. E.g. I have used Gargoyle for Level 9 games etc so that would be great.
I am happy to hear the idea of including Frankendrift in Parchment is still alive. That would be a game changer for Adrift 5. Even better if it also works with the site generator
Parchment is basically Gargoyle for the web. It’s a Glk implementation, just like Gargoyle, that includes many of the same interpreters that Gargoyle has. For Level 9 specifically, it looks like Parchment doesn’t support it, and Dannii can answer if that’s due to difficulties building the Level 9 interpreter with Emscripten, or it’s just not yet something that’s been implemented yet.
If you’re interested in Gargoyle for the web due to its abundance of interpreters, then Parchment is still your project: it’s built for the web and it would be no less work getting interpreters built for Parchment than Gargoyle, as they use the same code. That is, if an interpreter can’t be built to work with Parchment, it wouldn’t work with Gargoyle on the web either.
The primary difference between the two, were Gargoyle ported to the web, would be appearance: Parchment is a proper web app, i.e. using CSS, HTML, etc. Gargoyle would not feel like a web app in any way: it would simply use it as a canvas to draw onto. It’s the same reason Gargoyle’s not friendly with things like screen readers: even on desktop Gargoyle isn’t a “proper” program: it bypasses the OS for text rendering. That’s why it can look identical across platforms: it treats the OS as a canvas and it paints on it. The OS can’t tell it’s text, if that makes sense.
Anyway, when it was first released the “magical” thing about Gargoyle was that it bundled basically every interpreter under the sun with a new Glk implementation. It felt like a cohesive “play all the IF” program. But the real magic is Glk, which happily means that other Glk implementations can do the same thing Gargoyle does. And that’s what all Dannii’s work with Glk on the web has allowed: Parchment can currently play Z-code, Glulxe, TADS, Adrift4, and Hugo.
Nobody has actually requested that Parchment support another format, other than Adrift 5, in years. Some of the other interpreters might be trivial to add.
The next one I was thinking of adding for my own sake was Agility. Both to test the multiple file loading system, and also because it has nostalgia value for me.
Thanks for explaining that to me. It sounds like both projects (Gargoyle and Parchment) are cooperating some, which is great. I have been following Parchment on GitHub and it is clear that so much is happening there, and you are both doing this in your spare time, so I am all grateful for that.
Sure, I am eager to see Adrift 5 support as many of those games there are released at the moment do not get much attention due to the current limitations of interpreters but I hope the authors hold on until a web interpreter is released.
I am primarily concerned about Adrift 5 so I hope that one will get prioritized, but I understand that there are many other things to improve on Parchment and as you say, it requires an improvement on dotnet - I am not into that so I don’t know if that has been fixed. In any case I am grateful for all the work you put into it.
The Level 9 interpreter would just be another nice thing to have running online - just an example why Gargoyle on the web could have been nice. But I now understand that Parchment is the multi-interpreter on the web.
I have a very specific bug report which is probably of little interest to actually fix as it’s unlikely to help anybody but me, but here goes anyway: I’m using Gargoyle in Linux, specifically Bazzite KDE. When using 100% interface scaling (much too small on my high res laptop display) everything works perfectly. When using anything higher (150% in my case) Gargoyle’s font rendering gets broken, becoming very blurry. Nothing I’ve tried in the INI file helps, so I think this is something deeper in the way the app integrates with the OS. The closest I’ve come to finding out what is happening is that apparently GTK4 apps get broken in this way when non-fractional scaling is used with Wayland desktops.
Please submit an issue to Issues · garglk/garglk · GitHub so this doesn’t get lost. I’ll see what I can do to reproduce (no high res display here, and I run KDE on X11, but I can start it up under Wayland to at least try some testing).
