Loaded question probably: Glulx or Z-Machine

I’m not so much debating the merits of one or the other, I’m curious what “make sense” in people’s minds to choose.

For example, I notice compass rose examples tend to use z-machine more. I also like that you can color text. Glulx seems to offer better text styling overall but seems limited to just two custom styles for the duration of the game. More complex layouts with Glulx seem possible but looking at threads here: (1) the extensions to support this are a bit muddy as they are brought up to date and (2) not all interpreters support the fancy stuff anyway.

Speaking of interpreters, it seems like you can have more options for releasing with an interpreters if you go z-machine (including things like Vorple).

I realize Glulx can store a larger game overall and I do realize that some constructs of Inform 7 may inflate the needs such that Glulx becomes necessary.

So, like everything, tradeoffs and whatnot. I’m just curious what others think on this, in terms of the rationale for choosing one or the other.

2 Likes

It’s a complicated question. Glulx has no way to do the inline-color changes of Z-machine so you could do 8 colors in the same paragraph that was a basic opcode feature of Z-machine. At one time, Glulx had a variety of extensive extensions to do windows, colors, animation, etc - but almost none of these extensions sets survived the migration to Inform 7 6M62 syntax changes. For example, extension frameworks like Glimmr ifwiki.org/index.php/Glimmr just don’t seem to work or have been updated to run on Inform 7 6M62. Some story authors are willing to work with old versions of Inform 7 and have a working set of extensions.

Another issue is that Google said in September 2015 (now 15 months ago) there were 1.4 Billion active devices running Android Linux. yet, there was no active or supported Glulx interpreter for Android. Where stable choices do exist for Z-machine. So it depends on where you would want to run your games. if you only intend to support web-browsers via Quixe/Parchment then this wouldn’t matter to you (and it is possible to run in a web browser on Android). I’m personally trying to crack the Android problem… so hopefully soon that issue goes away in choice.

1 Like

Good summary, thanks.

Orthogonal perhaps to your point is one concern I have which is that an extensions based system can become chaos if it’s not managed well. Case in point is exactly what you’ve noted: lots of extensions that don’t update to match the code of the core implementation that allows the extensions to be used. To be fair, these are battles any extension-based system has. Ruby has it with Gems, Python with … well, with anything, Node.js with NPM. But all of those systems have provided workable solutions to manage that. Those are probably lessons we could bring over to Inform. (Maybe. It always gets complicated when a system undergoes systemic enough changes but that’s why you have a deprecation path so that extensions continue to work up until a point.)

The interesting thing though is that it’s not like Inform has a massive release every few weeks or even months from what I can see. Which means any given build should be relatively stable for quite some time, which means extensions should have no trouble keeping up. I realize there’s a person-to-time factor involved there, of course, but that’s another danger you get when you have a vanilla system that ends up relying on a whole bunch of extensions. You have to consider the ecosystem you want to support and whether your active base can support that ecosystem.

The colored text thing was the most interesting to me in some ways. I’ll be the first to admit that too much color can be annoying. But Glulx definitely seems like a step back in the style department. I’m not sure why only two custom styles are allowed unless that’s some deep limitation of the code.

Interpreters are another interesting aspect. The Inform manual mentions Vorple support for Glulx around 2015. I’m assuming the lack of such is simply due to lack of time by various participants. Certainly with open source, more participants could potentially help out but, right now, I’ve found that even figuring out the nooks and crannies of the specifications can be a bit interesting, to say the least.

I guess overall it’s hard to see where Inform 7 development is really going. Clearly Glulx must be it because it’s the default choice for story format. And clearly Glulx has a better chance of keeping up with developments in Inform 7 (code constructs and whatnot). But it also seems like Glulx support is in an interesting state across the board. It’s sort of a catch-22. More people might stick with z-machine because of more options (or easier options), but Inform developers presumably want Glulx to be the future. Thus you really need more people focusing on Glulx to make that happen.

I’m just rambling at this point, I guess, trying to feel out what the current situation is. Maybe this is the better question:

Who are the “Inform developers”? I see different people seem to write the IDEs. Obviously many different people write extensions. Some people are writing specifications for various things. (It even looks like Inform 6 is still seeing updates?) Clearly some people must be developing Inform itself. Lots of names float around but who’s who? And do they participate here in the forums? And how do they most want or need help?

Well, it’s deeper than that in that Glk is a standard for multiple interpreters (Hugo, Level 9, Magnetic, Scare, Tads 2 and 3., etc). I think Glk made a fundamental choice of not doing something that Z-machine had as a feature - inline color changes. Right now, Z-machine devs has to go OUTSIDE Glk to do what they could have done before Glk came along. It was hopeful / wishful thinking that I think Glulx would take over - but more than anything I think the history from today backwards shows it to have been a mistake to not properly address colors. In another topic here I even posted it as a “Christmas wish” that this be extended and at least be defined in the Glk standard. I posted this diff: github.com/BroadcastGames/Infor … fac2ba40b9

Z-Machine has its uses, but I think it’s sort of like how Windows 95 and cassette tapes held on for so long as stalwarts, but eventually it just makes sense to move on to a more modern format. It’s a shame that gblorb files can’t be made to work in Android consistently since it is a modern mobile OS.

Text coloring and formatting is one of those things where you can’t predict how people will play your game. One of the solutions that I really wish could work is a program I found that could wrap a website into a standalone .app file on a Mac (.app is sort of the OSX equivalent of a .exe file.) Using that, you can control text formatting via CSS and make the app look exactly like Inform’s publishable website with an interpreter (image display, but no sound) without being connected to the internet and without needing to worry about browser versions or multiply-capable interpreters. The negative is A: This doesn’t exist for Windows without jumping through some slightly more complicated hoops, and B: The developer of the Mac utility intends it for creating personal apps and requests that they not be distributed - no license. Otherwise this type of distribution could be perfect as it bundles everything into one sensible file that the end-user just runs natively in the OS.

I think you may be overlooking that many people view these as "emulators’ who run already-created story files that never had source code released. Much like a Commodore 64 emulator or a Nintendo 64 emulator. So a lot of work has gone into stable interpreters - allowing people to run these old stories on new devices for people who want to share old stories with their children, etc. So “leaving it behind” would only make sense to an author who is sitting down to write page 1 of a new story.

Interesting. Along those same lines, but different implementation, when I was last on the scene, TADS 2 was it. But I notice that TADS 3 has been around for some time and looking at its WebUI, that is quite powerful. You can essentially use the full range of JavaScript and CSS directly, with no intervening layers. I haven’t played with it enough yet to get a good feel for it but the small experimentation I’ve done so far seems to show it as an eminently practical example of what can be done.

I realize that has no bearing on z-machine concerns and Glulx (and Glk) is still enough of a black box for me to be uncertain enough to risk too much commentary at this point. The design rationale of the TADS 3 system is clear enough: leverage existing technology. I don’t entirely get the design rationale of Glulx yet, particularly if it wasn’t bound to the z-machine historical aspects at all.

I think what motivated a lot of it was size limitations. if you used too much text (or related lookup) in your story - you would run into limits. If you ignored all the visual aspects - Glulx allowed you to lift those limitations of story content size without having to rewrite your Inform 7 story itself (same source code, and no having to change IDE). You can just go in and compile to a different virtual machine standard. If you stick with black & white single-window interfaces that just use bold/italic you could make the change with no real effort.

The Inform 7 compiler is Graham Nelson. The various IDEs are supported by different people on different platforms.

The Inform 6 compiler is me and David Kinder, but we treat the I6 language as stable and only update the compiler for bug fixes and features needed to support the Inform toolset. DavidG is working on an Inform 6 library update.

I do the spec work on Glk/Glulx, although that has been stalled for a while as I work on interpreters and games and day-job stuff and so on.

Areas needing help: interpreter support is a biggie. Gargoyle gets occasional source patches but nobody is responsible for a release process or getting builds done. Mac Zoom and Spatterlight are completely out of date. Nobody is doing Android ports of anything.

If you know I6, I have a backburnered project to write up solutions and test cases for all the exercises in the DM4. (github.com/erkyrath/inform6-test) Contributions welcome there.

Creating IFDB entries for new games, and updating IFWiki, are community tasks that could always use more hands.

1 Like

Well, I guess I’m Mr. Nobody. I haven’t drawn enough attention to the Android Linux 1.8 billion devices not having Glulx interprter support? I commented to that fact in this very thread! What did run Glulx was largely ignored (zero comments) by this forum - Incant viewtopic.php?f=38&t=19740&start=0#p113081 - and I asking dumb C questions all the time to try and make progress. I spent 120 hours on Son of Hunkpunk with code on Github, little interest - I spent 30 hours on Twisty revival (24 months stalled) on Gihub with little feedback! Now I’m going from scratch using RemGlk as a base as it at least gives a way to do Glk beyond Z-machine that everyone failed at. Have you see the film named after me, Mr. Nobody?

And I’m really hoping your Android work will succeed allensocket. If you can get it stable enough to publish in the play store I think you’ll get considerably more interest. (And in general don’t think a lack of comments means no interest.)

I’m working on it. I’ve mentioned New Years Day as a goal. What I need is help from C programmers who understand these legacy systems. Makefile work on fizmo Request: C Makefile for Fizmo Z-machine interpreter Android , questions about the design of RemGlk github.com/BroadcastGames/Infor … fac2ba40b9 (right now the magic function garglk_set_zcolors is the “unofficial API for bypassing Glk”). All these things would help future developers, not just me. I’m really not trying to irritate or annoy people.

“Life is like arriving late for a movie, having to figure out what was going on without bothering everybody with a lot of questions, and then being unexpectedly called away before you find out how it ends.” ― Joseph Campbell, Creative Mythology

I apologize. I really didn’t mean to erase your work. I was just listing off the general holes that IF development has had over the past several years.

(I also said that nobody is doing Gargoyle builds, even though I did a Gargoyle build a few weeks ago. The point is that it’s an area that needs more volunteers.)

I support your Android work on Glulx (and will answer that question on Github in due course). It remains true that there is a serious lack of Android porting – dev tools, TADS, Hugo, testing of the theoretically-Android-compatible web interfaces, etc, etc.

Apology not needed. In fact, I want to say that the philosophical quote I just posted in this thread is true to the experience here. I’m not trying to annoy people with mistakes, errors and misunderstandings. I think there is a lot of ToDo labor on the table and people should be honest and open about the areas that need attention even if there is no ready army of volunteers. Twisty and Son of Hunkypunk devs have been otherwise occupied for the past 3 months - and it’s been a steep learning curve. My list of failures is long on this.

Android Apps and my learning curve:

  • history shows: Jul 16, 2014 Incant was on the community table. This runs Glulx and had unique things like speech interface. I researched the apps and came across one that had all the features that the community was missing. It runs a lot of stories that no other Android app could run. reference: [INFORM] The Reliques Of Tolti-Aph I spent about 30 hours on Incant before I realized I just didn’t have the skill to optimize Java performance on Android enough to make it worth the effort… and I admit I did not ask for help in that regard being even more a new member of the community (if someone wants a Java project - there you go. Incant is actually a unique and pretty decent implementation of an Interpreter on Android - but, on stories that are CPU intensive, it is slow. I found Bronze took 30 seconds on opening where on the exact same mobile phone I could use Google Chrome browser and Quixie and it run in ~ 8 second. I suspect much of that could be resolved in a matter of a couple days if someone had the right optimizing skills).

  • I looked at Text Fiction, which has nearly 100,000 installs and is a solid and popular Z-machine app for Android. It doesn’t seem to be getting active development - been the same release now for more than 2 years (September 17, 2014). It’s pure Java and only really built with one interpreter in mind, not really in the spirit of multiple interpreters - so adding Glulx to it would require making it multi-interpreter aware on top of the other work. I did spend some time with the code, got it to compile on the latest Android SDK, etc.

  • My next attempt was to explore what I had realized regarding how fast Chrome was with Quixe on Android. I was going to add it as a second engine option in Incant and even coded on this for 30 hours or so. 2 years ago this type of approach would have been painful because you would have had a 40MB download much like Lectrote is currently on Linux (having to bundle an entire web browser into the download). However, Google solved that problem in the most recent years (starting with Android 5.0 devices) as now the internal WebView gets updates from the Google Play store every couple months. So now the download size of a game + interpreter (Android app) could be just 1 or 2MB instead of 40MB that would have been in the Android 4.4 and earlier days. Alas, I found Glkote wasn’t as supportive of customization as I liked - not compared to Incant’s version of Glk. I then spent 15 or 20 hours on FyreVM to see if it had the Glulx core I could build off. But it has no interest in running ‘legacy Glulx games’ and currently focused on fresh-built (newly authored) stories. However, the general approach of Quixe as an Android app is there - and much like has been done with Lectrote - someone could make an Android app built around Quixe/Parchment. My heart just wasn’t personally into that approach at the time.

  • I then discovered that two apps, Twisty 2.0 (unreleased) and Son of Hunkypunk had in fact integrated the Git interpreter but were not willing to support it (and don’t expose it in the user interface). But, they were built with multiple interpreters in mind - and fast. I didn’t understand at the time why they were not supporting Glulx (which now at the end of December I understand - Glk windows, hyperlinks, and related features that Z-machine doesn’t really need to be implemented). I wasted at least 25 hours trying to figure out why I could not upgrade Son of Hunkypunk’s Git engine to the latest release! I started asking for community help now, as I was now over 30 days into trying to get a working interpreter that ran Glulx on Android. Reference; github.com/retrobits/son_of_hunkypunk/issues/36 - now I was getting into having to learn C and C++ which I really am not that good at. But ultimately found out that a single 64bit long value going form C to Java was my source of 25+ wasted hours! Then I spent another 20 hours or so trying to figure out what was absent in SOHP’s Glk implementation so it could do windows. I struggled and struggled with it’s highly looping code of going form C to java and back to C and my lack of ability to read terse C code wasn’t helping. I was hoping another developer would come along and help with the C side, but it didn’t happen.

  • Twisty 2.0 (unreleased) proved to be a valuable reference because it too had integrated Git interpreter independently of Son of Hunkpunk. It at least gave me motivation that I could learn by comparing both apps side by side. I probably spent 20 hours learning on what it had missing and it’s approach. It creates a monolithic C binary of all interpreters compiled together and loads them all at once. This is OK when you have 3 or 4, but when you start to get 8 or 10 interpreters like Gargoyle has - this approach to compiling and organizing the C code is limiting. Son of Hunkypunk goes a different approach and builds each interpreter as a loadable library in C and dynamically links them when needed. Much more complicated to master on Android - but I mostly got it figured out. reference: github.com/retrobits/son_of_hunkypunk/issues/41

  • Then I came to realize the true problem holding up the two main Android apps (Son of Hunky Punk and Twisty) was a lack of Glk that could do windows, hyperlinks, etc. I tried to follow their code and solve it. But I had too much trouble understanding the Glk windowing model. And the lack of Inform 7 source code samples for doing windows wasn’t helping. There is a pile of broken extensions and broken source code that won’t build on Inform 7 6M62 - and I wanted to at least understand the Glk windows from the authorship side of things. So I spent 15 or 20 hours producing samples of Flexible Windows code that run on Glulx to study what is missing on these various interpreters in terms of features. By now, my head is probably mixed up on which app can do what properly - but overall I found it difficult to deal with the mixed C and Java code approach in trying to flesh out incomplete Glk features. I think one of the apps (SOHP) had corruption problems with Glk Memory Streams that was the final straw of frustration with not understanding the C code of Glk. I just didn’t understand interpreters enough to fix the performance issues of Incant, nor enough of Glk to finish out Twisty or Son of Hunkypunk. But I had enthusiasm :wink:

  • Son of Hunky Punk has basically left Glulx not working. And nobody else has shown interest. reference: github.com/retrobits/son_of_hunkypunk/issues/36

  • I didn’t understand Glk enough to build a new app! Honestly, I think there needs to be more modern Inform 7 6m62 code showing technical demonstrations of Glk and a “Do’s and Don’ts” technical examples (in inform 7 source) for authors. A lot of extensions seem to have grown in year 2010 and 2011 that have since been abandoned (Glimmr etc). It would have helped me a lot to understand Glk better instead of reading a bunch of low-level C code and trying to understand GarGlk. I stumbled into NanoGlk and with my weak C skills tried to upgrade it form SDL 1.2 to SDL 2.0 - and tried to recruit developers to help get NanoGlk featured out - as Android can run SDL 2.0 apps pretty well. Probably spent 20 or 30 hours on learning to compile SDL 2.0 apps for Android and reworking 1.2 to 2.0. But I wasn’t happy with the results - Unicode text doesn’t render correctly (a problem that fizmo’s SDL 2.0 implementation shares, reference: github.com/chrender/fizmo/issues/5 ). Trying to build a Glk that deals with different mobile screen sizes for SDL 2.0 was proving too confusing for me. No C developers appeared to help out ( despite the idea of SDL 2.0 coming up here relatively recently: An idea - SDL2 GLK for android, iOS, and desktop PC glulx )

  • The current fresh hope came in RemGlk! Finally with RemGlk I could see in plain output what magic goes on between an Interpreter and Glk! You could print it out on paper if you wanted, one frame of output at a time. Finally, creating a Glk window and tracing the code made sense to me :wink: RemGlk also got me out of the concept of measuring screen size on 1000 different mobile phones and thinking differently about arrangement of the Windows (which is kind of what “channel I/O” is all about in FyreVM). RemGlk does memory streams and files all in the C code, which SOHP tries to do hybrid in Java… and RemGlk doesn’t munge the Unicode! And, I could run much of the code on a desktop with RemGlk and not only target Android like you do with Twisty & SOHP more Android-integrated approaches. Well, train went off the track again - then I wasted 30 or more hours on finding out that stdin and stdout on Android is directed to /dev/null and making a solution for reliable Java to C stdin/stdout exchange for all of my 15 test mobile phones! My lack of hard-core C coding skills eats up so much time. But I finally solved the stdin/stdout problems on all my test devices and can dynamically load interpreters - works on every CPU and device I’ve tested!

Now compiled C interpreters as I understand it is how Apple mobile is ahead of the game. So why all this trouble when Android is made on Linux? Well, Apple hardware is unified and one and only one CPU architecture! An iPhone is an iPhone. C code on Android you are dealing with ARM + Intel (mostly tablets) + MIPS, etc. And 32bit and 64bith both. A lot of odd crashes and problems can come up that won’t happen on iPhone because you aren’t targeting multiple CPU architectures. And, me being weak at C, it’s like sticking my fingers into a meat grinder… one mistake in my poor C code can result in hours and hours of wasted time. I could have simplified things and said “32bit arm7 devices only” and gotten things done faster, but I guess my feelings of C inadequacy got the better of me. I spent a lot of time over the past 3 months mastering the C (NDK) reliability issues related to these interpreters on multiple devices - as Android is very unforgiving if the C code crashes - it abends the entire application (Android is much more forgiving on Java crashes). I had abandoned Incant based on performance, but I couldn’t have random crashes (which was probably one of the reasons Son of Hunky Punk had decided to not support their Glulx efforts further).

My perspective now is that RemGlk is a live project getting some decent attention. I’ve been building an entirely new app on top of that. RemGlk’s graphics support is coming in shortly. So I feel it’s a decent enough approach (I’m happy with the windowing I’ve coded on Android). It’s surely not how most people would go about building an Android Interpreter (by consuming JSON). Alas, it made Glk’s behavior and debugging understandable to me in ways that Twisty and Son of Hunky Punk’s coupled Glk had me always feeling lost in problem-solving. I suppose with my now better Glk understanding I could revisit the Java code in those two apps with fresh insight. Now, for example, I fully understand Glk timers which I struggled with a couple months ago trying to add to SOHP :wink:

At some point, an actual app needs to be put up. I want to do that. But I wrote all this to kind of make a point: there is a long trail of incomplete work out there. Somebody could pick up Incant and optimize it… Incant was largely ignored by the community. Son of Hunky Punk has 10,000 installs and a 4.2 rating on the Play Store - and already has Git integrated in it’s compile chain - wake up the devs to integrating Git interpreter or fork the app and publish your own. Somebody could help me with RemGlk and getting some of the desires finished out, etc. Still laboring…

Anyway, thank you.

1 Like

Just to confirm, the Gargoyle everyone is talking about is this one, right? github.com/garglk/garglk/

In general I know there are there interpreters like Vorple, Quixe, Parchment. I’ve seen mention of TextFyre here and there but it’s unclear to me entirely what that is yet. Still researching. I guess a question is this: is the general consensus that web-based platforms are preferred? It seems like a very viable approach although I do realize web platforms can introduce their own complications.

Yes, that’s the latest source code for Gargoyle. FyreVM is a Glulx only interpreter for Microsoft toolchain plover.net/~dave/blog/fyrevm/ - it’s main concern is to do what’s called “channel I/O” where instead of the standard 80x25 text window focus it splits all output elements into flexible streams. At least that’s how I understand it’s primary concern. It doesn’t use the Glk concepts of windows, input, etc. It also can be compiled to run in a web browser - on par with Quixe (without GlkOte).

is the general consensus that web-based platforms are preferred? Quixe used to have some features missing (years ago) but most of that is now addressed. It’s a pretty solid runtime in terms of feature support. And it binds with RemGlk (supports remote protocol where interpreter can be on another system independent of the user). Quixe has the advantage of appearance and features no matter where it runs - as Lectrote has demonstrated even it’s appeal on desktops when traditional compiled apps get behind (recently Apple desktop upgrades broke some keyboard issues with the established apps and Lectrote stepped in to solve that quickly - during the middle of an IF competition).

I’d say there two key focuses to keep in mind: Some people want good emulation to run old stories/games that are in binary form. People are running data files that are decades old and want the Interpreters to best adapt them to modern systems. Others here are interested in authoring entirely fresh stories using source code and want specific features that are more modern/flexible.

FyreVM is the Windows/C# version that I never use anymore.

There is now a pure TypeScript version called glulx-typescript on GitHub. From there I’ve created wrappers that I call fyrevm-web. The last leg in the fyrevm-web journey is nearing completion. In order to get authors to use it, it needs a standard template that matches what everyone is used to, at least out of the box. More fancy templates are the goal and I will do that on my own next year for a comp game. The latest development takes glulx-typescript, my fyrevm-web components, and integrates ReactJS/Semantic-UI to create a clean web app code base.

The latest code is on github at plover.net/~dave/fyrevm-web/standard/.

The main difference for all of the fyrevm implementations is that there is no glk and no windows definitions or even styles to work with. I leave that entirely to HTML/CSS. The default italic and bold come out of the standard code, but anything else (colors, layout, hyperlinks) all require extensions and special I7 encoding and then a client that knows where to put content. I have a hyperlink extension, layout is via pre-defined templates, and colors can be done through CSS styles.

I appreciate your work, allensocket!

I think people tend to focus on and be more knowledgeable about the mobile platform they use. I know I’m guilty of skimming or skipping some stuff about Android because I use iOS primarily.

I can understand your frustration though. It’s similar when mainstream releases completely disregard or discount the existence of the Mac platform completely.

See reply to Zarf and “Textfyre” is officially a closed company. The remnants of the code are on my github page (github.com/ChicagoDave/textfyre), but I no longer reference that name in any IF work that I do.

It’s just fyrevm-web and eventually ifpress.org (which will be a hosting platform that supports fyrevm-web templates).

No-one else commented on this, so here’s my take: Zarf has basically said that he’s abandoned Glk’s original “style hint” model for colours and styles in favour of a HTML/CSS model, so we can’t expect him to do any more work on it. This doesn’t mean that someone else can’t come up with something, which could be popular, but really it requires an “end-to-end” solution, consisting of

  1. A change to the Glk specification, and
  2. An implementation of that change in at least one popular interpreter, and
  3. An Inform 7 extension to use it, along with at least one example to demonstrate its use.

This is all rather a lot of work, but not impossible. The really open question would be how to change the Glk specification, as there are several possibilities that I can think of (there are probably others):

  1. Just add a bunch more styles to the specification. It’s not completely clear to me what you’re proposing in the referenced GitHub commit, but it looks like basically this is what you’re doing. I would suggest they should be “style_User3”, "“style_User4” etc. so that all you’re saying is that there are more styles to play with, not that any new ones act any differently to the old ones. The advantage of this is that it’s pretty simple. The disadvantage is that it’s still not as flexible as the Z-Machine colour model, especially not the (admittedly not really ever used) arbitrary colour support included in the Z-Machine 1.2 spec (see the section on “@set_true_colour” in http://www.ifarchive.org/if-archive/infocom/interpreters/specification/ZSpec11.txt).

  2. One step up would be to allow arbitrary numbers of user styles to be created. You’d need to add an extra Glk call that allocated space for another style and gave you back the appropriate index for it, something like

glui32 glk_create_new_stylehint(); This would allow arbitrary numbers of styles (up to some limit in the Glk implementation, possibly), but it does mean adding an extra function to the Glk specification, so an extra work step would be to add the appropriate logic to the dispatch layer so that the game could call the new function through the interpreter. Also, the result still isn’t as flexible as the Z-Machine colour model, since you still have to choose all the styles you need in a window before the Glk window is opened.

  1. A different approach would be to work around the limitation in Glk that the styles have to be set before the window using those styles is opened. You could, for example, have a Glk call that updates the style hints for a given window without changing the display of any previous text, something like:
void glk_style_update(winid_t win);
  1. A final approach would be to bypass the Glk stylehint model somewhat, and add an extra Glk call somewhat in the style of the Gargoyle extension you mentioned, which would set the text foreground and background colours directly, regardless of what styles are in use, for example:

void glk_colors_set(winid_t win, glsi32 fore, glsi32 back); The advantage of this would be that it would be easy to write an extension to use this, as it would be separate to the style model as is.

In addition to all this, there needs to be some way for a game to test whether the interpreter supports the chosen extension: you can’t simply call an additional Glk function without knowing if it’s supported, as otherwise the interpreter will almost certainly halt the game with a fatal error. The simplest solution here would be to add something to the Glk Gestalt model: you’d need a new number for a new gestalt selector, ideally from Zarf, so that your extension could use Inform 6 code like

if (glk_gestalt(gestalt_StyleExtension, 0) ~= 0 { glk_colours_set(win, fore, back); } I suspect to get traction someone would need to choose an extension approach, implement it in an interpreter, make an extension and then hope it proved popular.

2 Likes