RemGlk 0.2.4

Okay, after several weeks of (admittedly intermittent) work, I have a new version of RemGlk which supports graphics.

This has not been heavily tested. I went through some of my test Glulx games that can draw images and rectangles. I fired up Sensory Jam. I connected RemGlk+Glulxe to the regression-tester and to the remote-if demo.

(As part of this, I extended to be able to check images and graphics commands. This is not yet well-documented.)

Great work! I’m building the new Android app called Thunderword on top of RemGlk. RemGlk has in many ways made things much easier. I just posted an issue about how RemGlk seems to sizes the images in Counterfeit Monkey in a suspect way. Thank you for the work!

I was looking over your page and realizing I wish I had noticed GlkLoader earlier :wink: Anyway - I found out there is a newer source code set for GlkLoader I found here:

Thanks to some community help, I got past my understanding problems. Needed to rework my logic to use pixels instead of characters as a unit of measure.

A suggestion for RemGlk and client (GlkOte): add a second demo of using WebSockets to feed the JSON input/out. I found a wrapper for doing this easily:

Sharing some quick and dirty Ubuntu instructions for binding RemGlk with Glulxe interprter, start in an empty directory:


git clone
git clone
git clone

cd remglk

cd ..

cd glulxe

echo "*** Makefile needs to be revised to pick RemGlk"
echo "***"
read -rsp $'Press any key to continue...\n' -n1 key


cd ..

RemGlk wish list, which has me pretty stuck at the moment… if RemGlk is waiting for input from the remote system, I think a JSON “stopterp” command is needed. What’s especially important is that it properly frees up all the C/C++ resources and returns to main to return a normal int value. Be it an internal error or requested stop, I need it to avoid exit() calls or assert() in the middle of the code without returning to main. Right now, RemGlk is waiting for input char, input line, timer - and adding a ‘stopterp’ JSON call that would properly exit the interpreter (be it Glulxe, frotz, nitfol, etc) and close up resources and allow a C function to wrap main(argv) and change out interpreters… such as going from a Glulx to Z-machine story. If the player does a proper stop of the game by doing “quit” everything works fine with RemGlk exiting to the main function() - but the syntax for “quit” isn’t universal - as various fiction stories have altered the behavior and prompts.

RemGLk is kind of the app you run, and it having a “stopterp” command that does proper exiting would really serve to demonstrate this for anyone coming along and looking for code examples of how to build a multi-headed app that Gargoyle that knows how to be a Glk for many different engines.

Any help at the code level on this is appreciated.

The supported way to do this is to close the file descriptor connected to remglk’s stdin pipe.

If you need something to happen at exit time, that’s not really possible with the way the interpreter is set up; the game can always call glk_exit() or the @quit opcode to shut down. You’ll have to explain what you need in more detail.

My desire is born out of some technical limits of not being able to ‘unload’ C code in my same process that doesn’t perfectly free up all it’s memory and resource. Right now, RemGlk works great as it is written if I tell the game to quit through it’s normal Interactive Fiction input. The interpreter is stopping it’s code execution and Remlk is freeing up it’s resources. But how can I force the same exit paths on-demand, force-close a RemGlk + interpreter? Glulxe linked with RemGlk, load, start game, unload. Frotz linked with RemGlk, load, start game, unload. I don’t have a protected sandbox to run it in - and Android is brutal about the C code crashing the entire application. I’ve tried jumping in and calling glk_exit() and gli_fast_exit() but it’s not working the same way as a proper story exit and crashes my app.

Your comment about stdin actually might be pointing to me a solution. Because I had issues of spurious loss of stdin on some hardware - and I actually had to offer complete replacements for getc/ungetc that data_raw_blockread_sub(char *termchar) in RemGlk is using. I mention this, as now that I think about it, I think you are right that it does safely exit with that spurious lost of stdin. A null sent to stdin (which was the oddball hardware spurious interpretation from RemGlk) reaching gli_fatal_error(“data: Invalid character in data”) was what it looked like. I’ll play with gli_fatal_error(“data: Invalid character in data”) being a ‘safe exit’ that doesn’t abend the entire app.

I know it seems more than Glk was intended, and maybe it’s naming (of Glk) alone - but it’s pretty clear to me that this is what is needed: standard API conventions for safely loading and unloading stories + interpreters. RemGlk is the “app”, and a remote system across TCP/IP would seem logical to keep with a JSON command to “unload” RemGlk so it has a safe exit code and can be looped to start with another set of args and init. I hope everyone is having a good start to the new year. Thank you.

EDIT: RemGlk relies on exit(0) in … isc.c#L168 I’ve made some progress learning setjmp and jmp_buf to get back to main - and making sure that both functions free up resources (gli_display_error doesn’t do this).

Quick update – version 0.2.5. Contains bug fixes only.

version 0.2.5 seems to be crashing for me on several stories in gli_windows_update (called by glk_select), using Git interpreter. I haven’t had time yet to bisect the commits to find why. I’ve gone back to 0.2.4 until I have time to investigate further. Thank you.

What games?

Some work (Freefall/Tetris works), but most crash for me. For example: … lx/ City of Secrets v3, on Glulxe interpreter. Answer first two prompts (space twice) and a signal 11 (SIGSEGV) in gli_windows_update. I just integreated the changes committed in past 24 hours, still happening.

I could have made my own mistake, I still need to back out some of my own changes, but so far it looks like it’s something added between RemGlk 0.2.4 and latest.

EDIT: Is there some place in the code that I can remove the variance in the Glk window ID so it’s the same ID for the same data file every time RemGlk starts? it would make testing for this kind of crash easier to split out from my main code as I could just pipe in JSON blindly for quicker testing.
EDIT 2: rgwindow.c function gli_initialize_windows line

seems to be our source of variance with window ID each restart of RemGlk? I’ve hard-coded it to start with = 24 until I track down these crashes.

Ok, so I can’t seem to reproduce the crash on desktop, so it might be something with my own code. Changing tagcounter to non-random has made testing a lot easier. set tagcounter = 24 to use the input below.

$ ../glulxe/glulxe  CityofSecrets_v3.blb

{ "type": "init", "gen": 0, "metrics": { "width":720, "height":400, "charwidth":9, "charheight":16 }, "support": [ "timer", "hyperlinks", "graphics", "graphicswin" ] }

{"type":"char","gen":1,"window":27,"value":" "}

{"type":"char","gen":2,"window":33,"value":" "}

{"type":"line","gen":3,"window":33,"value":"go north"}

No crash, so it must be some mistake I’m making elsewhere. I’ll keep digging.

EDIT: Removing the random window ID has greatly simplified the cross-compile run-time testing. So far, no crash, so it must have been another mistake.

EDIT-2: Found my screwup, had one data structure with the old dirty begin end and not the new update. Not sure why the compiler didn’t catch it.

I tested CoS myself, just to be sure. Yes, it works as far as I can tell.

Thank you. I’ve confirmed it was my mistake, mismatched data structure. I’ve reorganized all my RemGlk usage to be able to better reproduce issue with clean builds on desktop and this should cut down on my false problem reports.