Loaded question probably: Glulx or Z-Machine

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 https://intfiction.org/t/request-c-makefile-for-fizmo-z-machine-interpreter-android/10905/1 , 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: https://intfiction.org/t/inform-the-reliques-of-tolti-aph/67/1 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: https://intfiction.org/t/an-idea-sdl2-glk-for-android-ios-and-desktop-pc-glulx/9793/1 )

  • 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.

1 Like

So what about the fyrevm-web thing mentioned above? Isn’t some of this exactly what it’s doing? Or trying to do?

I’m getting the feeling that there’s a lot of disconnected work going on rather than a gathering of forces. That could be completely wrong on my part.

That’s Dave Cornelson’s project to try to do something a bit different: it uses the same underlying virtual machine architecture (Glulx) but with a different I/O layer (FyreVM instead of Glk). Glk was an attempt to define an I/O layer that would work in the desktop world as well as the web: FyreVM is an attempt to re-think the text adventure display model in terms of modern web technologies (I’m putting words in Dave’s mouth here).

People work on whatever they’re interested in: sometimes that will be building on previous work, sometimes doing something completely new, and sometimes a combination of the two. I don’t see anything wrong with that.

I completely agree. I never said there was anything “wrong” with it necessarily. But if there’s already been a great deal of investment in work in a particular approach it might be worth seeing if some focused effort towards taking that to its conclusion (or a conclusion) is worth it. Sometimes people choose their own path because they aren’t aware of the existing paths that might be more fruitful.

As others have noted, there’s a lot of half-completed or partially-started work out there. Clearly a lot of experimentation, which is healthy for an ecosystem. But there’s also nothing “wrong” with a focused effort in a relatively few directions rather than a defocused effort in a series of potentially orthogonal directions.

For example, in your phrasing if “FyreVM is an attempt to re-think the text adventure display model in terms of modern web technologies”, it looks like this is something that TADS 3 tried to do with its own model of the WebUI. It sounds like there are at least two implementations of this idea to learn from, which I think would be interesting, particularly if, as you said, the previous styling system of Glk was being changed more to an HTML/CSS type approach.

Keep in mind I’m an outsider looking in. There’s not a lot of good roadmaps, that I’ve found anyway, to what paths the community has tried, not tried, wants to try, etc. It’s only by providing a few prodding questions that you can even start to gain a semi-coherent picture. That’s currently the phase I’m in.

Regarding areas that need help–there’s a to-do list for interpreters (among other things) that was put together a year or so ago.

If you want to know more about who has contributed to Inform 7, its page at IFWiki is a good place to start.

It’s actually your final item on the list that I’m talking about avoiding. Z-code already has a set color opcode and Inform 7 already has a syntax for changing text colors - and I pointed to Gargoyle’s function garglk_set_zcolors() - which was actually implemented in some of the existing Android apps as a way to get Z-code color into the fold. Z-code Inform 7 knows how to produce these color calls without any extensions at all. Basically I mean the foreground text colors. Then, if someone wished, they could add the extra styles to Glulx extensions that already use User1/User2 and and treat them as an extra set.

It’s nice to say ‘abandon stylehints’ - but that’s overlooking the point there are hundreds (thousands?) of stories out there already compiled, without source code, that make use of stylehints! My focus right now is on Glk + Interpreters (multiple interpreters) and easier portability. It was an observation rooted in experience born out of reviewing Android apps with 3+ different implementations of freshly built Glk type layers. stylehints are difficult because the properties have to be set at the time of the window creation - and combining that with a very small set (user1/user2) has left Z-code colors closed out of the Glk system.

This year’s hot Christmas gift was a Classic Nintendo with a modern HDMI port to hookup to a fresh television set. I honestly have to say that the 3 major Android Interpreters (Text Fiction, Son of Hunky Punk, Twisty) seems to be under the keys of developers who are perfectly content with Z-machine only. Two of them have played with Glulx (Twisty, Son of Hunky Punk) but have left it on the back burner for years. I think it’s a mistake to slight z-code which has colors as a first-class opcode. It isn’t going away.

That’s not going to work. If you’re compiling to Z-code, then either you write Inform 6 directly, or the Inform 7 code is compiled down to Inform 6 syntax, but ultimately in either case changing the text colour in Z-code will reduce to an Inform 6 line like

@set_color 3; ! use red But when compiling to Glulx, that means nothing to Inform 6: it will just generate an error. Instead you must have one or more Glk calls to do whatever you want. If you look at the I6 template files (those ending in .i6t) in the Inform 7 installation, you can see such calls are emitted for Z-code only. Whatever you do, you are always going to have to provide some sort of Inform 7 extension to actually make calls to make the color change happen. There is no way to avoid this.

A .z8 file is ALL Z-code! It doesn’t emit Glulx to do this! I’m talking about z-code here, targeting .z8. Again, I know all this. And my proposal change (~20 lines in Glk.h) is STRICTLY between Glk and Interpreters. Inform 7 does not need to change. What you just described, “it will just generate an error”, is exactly what happens today in Inform 7 IDE!

inform7.com/learn/man/RB_12_1.html

say " [item] ([front side of the item]/[back side of the item]): [if the item is locked][green letters]LOCKED[default letters][otherwise][red letters]UNLOCKED[default letters][end if]";

Glk can not deal with this public syntax once you go beyond 2 colors! That’s the reason Fizmo Interpreter uses an out-of-band call to Gargoyle garglk_set_zcolors to get more than 2 colors - when it uses Glk for everything else!

Let me point out what may not be obvious context of this requested change: When writing an app for Android tablet or Ubuntu desktops - most of the work goes into Glk! The interpreters are already out there and decade-old C code compiles fine. It’s Glk that is the middle API that is all the labor of making an application. Son of Hunky Punk is the perfect example of this - it has TADS, HUGO, Z-code interpreters, Glulx interpreters - almost all the labor of adapting Interpreters to a platform is in the Glk work! We have multiple Z-machine interpreters (like 10 of them) and multiple Glulx interpreters (Git and Glulxe) that easily compile and adapt to any platform.

P.S. Just yesterday working on this more, I would also say that we could have one MORE style to the list. In addition to Z-code colors github.com/BroadcastGames/Infor … fac2ba40b9 I think one more style of style_WindowColour - so that Gargoyle’s technique of setting window background color (off Normal text background) could be normalized in Glk without interfering with style_Normal like it currently does.

Zarf has in the past allowed others to have a range of function codes and gestalt selectors to write external specifications for. So we could formally specify the additional Garglk functions. That would probably be an afternoon’s work. The trickier thing would be getting enough (or any) Glk libraries to commit to implementing them. If it would really help with your work on an Android terp for both Zcode and Glulx then I’d say that wouldn’t be a bad thing to do, even if our real future focus will be with the CSS extension. Zarf has reserved a range for me already so I could do up the spec for this.

However if you are still thinking of using remglk for the android app then a subset of the CSS functions would be more productive. I am already thinking about that for ZVM and Lectrote. This would not be as quick a process as formally speccing the Garglk extensions because we would want to ensure that it will fit with the eventual CSS extension. So rather than using the range of codes reserved for me we would want to suggest that a core subset be implemented in the base range of codes.