C programmers, Git interpreter on Android, Twisty

We have 4 attempts to get Glulx interpreter on Android that I’ve found in three weeks of research:

  • Incant uses pure Java (‘native Android apps’) and actually runs many games very well once you fix it’s 2-year old code for downloading games / opening them, except it’s slower than Quixe in the Android Chrome browser. Optimizing a VM is beyond my ability.
  • Son of Hunkypunk has integrated git and can run advent 100%. But, it’s git interpreter is several release behind on the latest release of git interpreter and when I update and compile it - it has some serious problems with not working (crashes on keyboard input). i don’t have enough C skills to really know what’s wrong here.
  • Twisty has a newer version of git interpreter integrated - and I updated it further to the latest version of git 1.3.4 without breaking anything! But, it is incomplete. I see that there is no ability to open ‘side window’ that git can do on a desktop.
  • AndroidIF has a custom interpreter - purpose built to run an author’s Inform 7 single game - with instructions on how an author can self-publish. It currently requires you to put an extension and compile with Inform 7 - so it isn’t really ready for running general-purposes Glulx games.

All 4 projects seem to have been sitting for 12 or more months with no effort on getting Glulx as a general app for players. I’m right now focused on Twisty because at least I can get run gluxercise tests on it with the latest git c code (git version 1.3.4 source off of github). And, for the record, git Interpreter seems incredibly fast on Android - I tend to use Bronze’s slow startup as a reference, it’s far faster than Quixe on Chrome on a desktop CPU!

I’ve hand-converted Twisty from Eclipse Project to Android Studio 2.2.1 using the gradle build system and SDK 24. This puts everything on a modern development platform. github.com/BroadcastGames/twisty

Now, the c code will compile with NDK 12b, but the latest NDK is 13 and changes compilers to clang. And there are things that need to be fixed, I was unable to build Son of Hunkypunk or Twisty without going back to the old NDK 12b. I’m hoping someone with some C coding experience can help out this week and we can get things on NDK 13 by resolving the errors (which may need to feed upstream to the various interpreter github projects). This can help porting in general, as really if git compiles on multiple compilers there is benefit for users beyond Android.

Any C programmers out there with some time to help do gcc to clang issues? And to help me try to figure out a strategy for dealing with c code crashes on Android (which produce nothing in the way of useful error like Java code does)?

I can potentially help with the Git-GCC-to-Clang part, but I have no experience with Android development.

EDIT: One problem stands out: Git casts back and forth freely between “uint32” and “void*”. Which works fine if you have 32-bit pointers, but really shouldn’t be relied on.

Clang by default only produces warnings for this, and it compiles and runs fine on my system. The unit tests fail spectacularly since I’m using cheapglk and the tests are based on Alabaster, but the text all seems fine.

I’ll see how much breaks if I change the uint32 to uintptr_t.

EDIT2: Turns out Git ensures that void*s are 32 bits and refuses to run if they aren’t. That’s one solution.

cool, let’s do it here. I’ll link to the github code with line. All of these seem related to the same problem?

app/src/main/obj/local/arm64-v8a/libnitfol.a(decode.o): In function `decode':
app/src/main/jni/nitfol/decode.c:55: undefined reference to `get_var'
app/src/main/jni/nitfol/decode.c:62: undefined reference to `get_var'
app/src/main/jni/nitfol/decode.c:70: undefined reference to `get_var'
app/src/main/jni/nitfol/decode.c:71: undefined reference to `get_var'
app/src/main/jni/nitfol/decode.c:152: undefined reference to `get_var'
app/src/main/obj/local/arm64-v8a/libnitfol.a(decode.o):app/src/main/jni/nitfol/decode.c:92: more undefined references to `get_var' follow
app/src/main/obj/local/arm64-v8a/libnitfol.a(op_math.o): In function `op_store':
app/src/main/jni/nitfol/op_math.c:30: undefined reference to `set_var'
app/src/main/obj/local/arm64-v8a/libnitfol.a(op_math.o): In function `op_dec':
app/src/main/jni/nitfol/op_math.c:91: undefined reference to `get_var'
app/src/main/jni/nitfol/op_math.c:92: undefined reference to `set_var'
app/src/main/obj/local/arm64-v8a/libnitfol.a(op_math.o): In function `op_dec_chk':
app/src/main/jni/nitfol/op_math.c:97: undefined reference to `get_var'
app/src/main/jni/nitfol/op_math.c:98: undefined reference to `set_var'
app/src/main/obj/local/arm64-v8a/libnitfol.a(op_math.o): In function `op_inc':
app/src/main/jni/nitfol/op_math.c:108: undefined reference to `get_var'
app/src/main/jni/nitfol/op_math.c:109: undefined reference to `set_var'
app/src/main/obj/local/arm64-v8a/libnitfol.a(op_math.o): In function `op_inc_chk':
app/src/main/jni/nitfol/op_math.c:114: undefined reference to `get_var'
app/src/main/jni/nitfol/op_math.c:115: undefined reference to `set_var'

Source code, line 55 of decode.c:
github.com/BroadcastGames/twist … code.c#L55

I notice this nitfol checkin goes back to April 2010 (the decode.c link I just shared)? And I find some references on this project to 2014 and clang? clang.debian.net/logs/2015-03-25 … _clang.log – so far, I can’t find anything newer than “release 0.5 of Nitfol” code. This decode.c has a distinctive comment “tick tock hickery dock the mouse ran up the clock” that I can’t find on Google search.

I’ve run into problems with Nitfol on my computer as well. (I eventually got it to compile, and load a game file, but once it asks the user for input it never returns.) If you want a Z-machine interpreter which passes through Glk, would it be possible to use Bocfel instead?

Or Fizmo.

I don’t know enough about each Interpreter to say which is best. Are the devs of Sons of Hunkypunk active here? Because it also includes
Nitfol and replacing it with Fizmo - can we go into details of what that might break? Are there any games that work best on Nitfol? github.com/BroadcastGames/son_o … c/main/jni

I see Sons of Hunkypunk has both Nitfol 0.5 and GlkFrotz v2.50? Why both? We have a common problem with the clang compiler on both apps…

I’m not sure what advantages one has over the other. Bocfel was the first one I succeeded in compiling with Clang, and Gargoyle uses it by default for all Z-code games; does Son of Hunky Punk contain logic for switching between them, or is it up to the user?

Looks like it’s unhappy with the way the INLINE macro is defined for function declarations. Maybe rip out that chunk of nitfol.h and replace with just “#define N_INLINE”.

Based on the keywords you just fed me, I came up with this reference on converting code to GCC to clang: stackoverflow.com/questions/2557 … -expansion - maybe it’s just a matter of feeding the right params in the right Android.mk make file?

I don’t see any way to force Son of HunkyPUnk to one or the other, but it does seem to display the one it will use before you actually launch the game. GameDetails.java line 396: github.com/BroadcastGames/son_o … .java#L396

 return (getZcodeVersion().compareTo("6") == 0) ? "nitfol" : "frotz"

So for a specific version of Zcode it seems nitfol is preference?

I also just found out where Twisty does it’s logic to pick interpreter (git or nitfol): github.com/BroadcastGames/twist … ain/main.c

In case it helps, the version of Nitfol used in Gargoyle has removed the “N_INLINE” macro definition. It also uses the following flags in the compiler command line:

-DSMART_TOKENISER -DDEBUGGING -DFAST -DUSE_INLINE -DNO_TICK

Nitfol builds (with lots of warnings) using Apple’s clang but I don’t know that it actually runs and works.

Ahhh. Z6 is the weird version of the Z-machine, where Infocom added sound/graphics/mouse input/bells and whistles in a rather haphazard way and (to quote the spec) “made a mess of the system of opcodes”. Many interpreters don’t support it properly, or at all, since so few games ever used it. Inform by default compiles to Z5, or to the later Inform-specific Z8. Do you think it’s worth putting in the effort to support it here?

Great news. Twisty 2.0 on Github is active - and a checkin related to CLang and Nitfol went in: github.com/garglk/garglk/commit … bc94866f5c - thanks for the help back in October and hope everyone’s New Year is starting off well.