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