I’ve been encouraging everyone make “the middle” bit based around RemGlk. The main absent things currently in RemGlk is 1) Glk style hints / text colors for Z-machine stories, 2) Glk sound support. I’ve had moderate success with adding style-hints to RemGlk - and I’m hoping audio will be done for me Performance wise, there is little reason to not use RemGlk - the overhead of going from Glk to JSON is very low - and it makes debugging Glk far simpler than something like the topic we are reading ( David Fletcher’s Qt Glk bubblycloud.com/qglk ).
Why did I come to Qt this past week? Because I started out following the approach Twisty 2.0 & Son of Hunky Punk were taking to back-end game engine, but ultimately I really got bogged down in how poorly the Android framework deals with console input/output (as in stdin and stdout). I’ve mostly solved these issues, but it took months of testing on a lot of different phones and tablets - and is still not as stable as I would like. I’m faced with a pretty messy code base now (in Java) and starting a rewrite… but now I"m considering outright moving to Qt for the back/middle and continue to encourage multiple front-ends be developed that trade JSON. (Thunderstrike is an app example of an independent front-end consumer app of JSON, and someone could make a GlkOte app that interfaces with the JSON - which is what is already basically available here: github.com/erkyrath/remote-if-demo - a GlkOte that uses JSON via RemGlk).
I know nothing at all of QML and it looked like a pretty steep learning curve, with XML layout files that get compiled and such that quickly reminded me of Android’s native layout system. If someone wants to make a RemGlk QML front end… please do! At this point, I feel like nobody else has shown much interest in jumping on the JSON RemGlk bandwagon… but I keep making noise of this key architectural change.
Specific to your request: I can share the Android.mk I made for RemGlk + Glulx if you want, you will need the Android NDK to compile it. I tried but was unable to use more traditional cmake/make but couldn’t get the cross-compiled binaries to not crash on Android. Perhaps that problem can be solved, but I ran out of time.
On the bigger topic: Earlier in this thread I made a ‘request for help’ on some bash scripts or makefiles that can compile all the terps from Gargoyle linked to RemGlk instead of GarGlk. I think it would really help if there was a “IF engine project” set of scripts for a standard directory structure and list that all apps should share. And ideally the script/makefiles dual licenses to allow both GPL and BSD. As Gargoyle is GPL, and that can be a problem for some projects… dual license would be better.
What I suggest we need is an open source bash script project that can:
github checkout all the terps individually (or wget, etc) from their most up to date sources.
github checkout various glk engines. RemGlk, CheapGlk, GlkTerm, etc.
Compile a set of binaries for the platform (Apple desktop, Linux desktop, Android, Windows 10, etc) linking all the terps to the selected Glk.
I’m pretty poor with bash and multi-platform compile scripts. That’s why I put out a request for help. I think it would further multiple efforts to have this common open source base.
For Qt widgets, I managed to figure out how to override the Android-specific layout issues (vertical scrollbar width, QComboBox font issues) with 2 lines of code.
Here is a new screen shot of Bronze with color added to highlight the altered Qt elements:
Anyone motivated to hack on this in the short-term, as in now, let me know. I’ve been happy enough with my learning progress of C++ and Qt to put some more effort into this. I now have some decent-enough sanity checks and error handling on the Git/Glulxe/Z-machine/etc engine launches. I have char and line input working pretty well, even auto-complete specific dictionary for IF working; the Glulx story Six opening prompts for configuration are all now satisfied. If anyone wants to be active now, speak up, and I can make extra effort to push progress to GitHub.
Qt’s JSON objects are actually pretty similar to Java’s JSON objects. So the learning curve on JSON hasn’t been too bad.
Related to wishing requests: I still really wish we had a community open source bash script for building all known Glk interpreters with RemGlk on all the main operating systems (Mac, Windows, Linux).
I agree that this would be very useful. I pulled out all the interpreters for a private project where I was building them all against glktermw, but there’s really no clean way to stay up to date with Gargoyle, other than manually copying things over.
To at least start with, I’ve created a ticket against garglk to at least make the included interpreters build against non-Gargoyle Glk implementations. Long-term it would probably be nice to be able to have a collection of interpreters that can be reused by anybody who wants to do a Gargoyle-like project against other Glk implementations.
I agree with what cas commented: Ideally you can pick CheapGlk, GlkTerm, NanoGlk, RemGlk, etc - and have it run through building all the Gargoyle terps against those Glk’s as stand-alone binaries. As an observation: The wind seems to be blowing in the direction of CMAKE as the new standard for makefiles.
You mean the app Qt C++ code to parse the JSON coming out of RemGlk? The screen shots earlier in the thread of Bronze running? I posted on blog yesterday that I’m gong to be releasing that with a BSD license. blog.wakereality.com/2017/08/det … emglk.html - I will publish what I coded on GitHub this week. It isn’t that pretty, but it’s a useful enough technical reference and I hope inspires people to work on consuming the JSON to better visual interface and localization for desktop/whatever.
I have tried to compile some of the terps and seems not to compile (I guess that’s the main point of doing this). So, maybe I start collecting links of projects.
This gives you two of both Glulx and Z-machine engines to run, which I find is good to have a testing surface for developing a Glk layer.
Also seems frotz is another backend for Z-machine, and Son of Hunky Punk has a frotz makefile for glkfrotz - but I think it’s older source code github.com/DavidGriffith/frotz
EDIT: Before edit, I was confusing Frotz and Fizmo
Fizmo is being actively developed this year and even has a RemGlk interface: github.com/DavidGriffith/fizmo - For example, Fizmo has a SDL2 implementation that isn’t a “general-purpose Glk”. And Fizmo isn’t in the Gargoyle backends. But it could be, as there is a Glk layer.
Related to discussion of a Make system for building the Gargoyle terps away from Gargoyle itself… I’ve uploaded a new project to GitHub to buidl RemGlk+Glulxe using the CMake system to cross-compile to all the CPU variations of Android. It hasn’t been tested much, but it does compile github.com/WakeRealityDev/IFTer … droidCMake
I’m running a bit behind on this, should be published on GitHub in the next 3 days. I put together a ToDo list of all the missing features that will go along with it if someone wants to keep coding on it to make it more of a full Glk.
Ok, Qt 5.9.1 project is now up on GitHub: github.com/WakeRealityDev/Thunderquake_Qt - project name of “Thunderquake”. If you have problems getting it to run in Qt Creator - let me know and I will do my best to be responsive on making suggestions and sorting it out.
Thank you.
I have tried to run it. I’m on Qt 5.6.1 as I’m pretending to run it on Ubuntu in the phone and that’s the modern Qt as it takes.
And I run into this:
Trying to run the project on the desktop it doesn’t find QJsonObject nor QJsonArray (because of the Qt version? I have looked for differences in the version from 5.6 to 5.9 but I can’t find it as a new feture)
Trying to build it for the phone stops at
remglkprocess.cpp:431: error: 'class QTextStream' has no member named 'readLineInto'
if (dataTempStream.readLineInto(&line))
^
Can you show me the way? Is it even possible to compile against Qt 5.6?
For all the labor this code will require to finish, I personally don’t see any reason to not use the latest tools. My interest in it was to break outside of pure Android Java I was working with before - and I probably have 3 major choices of interest to me: 1) SDL2 [update NanoGlk to SDL2], 2) Qt, 3) a “game engine” like Cocos2d. It never even crossed my mind that someone might want to use older Qt tools. As that’s kind of what I was trying to step away from - all the variations Android has between version 4.4, 5.0, 6.0, 7.0, 8.0. I steered clear of Qt Quick Controls entirely, as I want to know the ‘fundamental Qt’ before getting into all that XML layout stuff, and Qt Quick Controls 2 breaks a lot from previous.
My motivation for drawing attention to this is I wanted to toss the idea out of an alternate to Gargoyle and it’s GarGlk - built on top of RemGlk. Overall, really, just something cross-platform that isn’t GTK… which other than the paper Kindle models, GTK seems to be unfriendly to mobile. I’d really like to see SDL2 get done, but I don’t have the right software skills. However, Fizmo is out there with SDL2 that could provide a good reference model to turn into a multi-terp Glk: github.com/Sturmflut/ubuntu-touch-sdl-template ).
I can download 5.6 and see what problems come up. If your target is a phone, I’ll warn you up front that this code expects a mouse for scrolling a scrollbar on the right side… it doesn’t have any touch interface. The whole thing is pretty incomplete.
I also wanted to port to Qt with qtquick (before 2 that, as you say, breaks everything). Also, it’s supposed to be al easy and portable, and probably is but I can’t manage to do a lot of things (because I lack programming skills).
I’m using QtCreator 4.1.0 with a lxd container for the phone (instructions on how to do that). Even that is not maintained anymore by Canonical could be an starting point for the desktop (and UBports keeps on developing images for the phone).
For the phone interaction, the UbuntuComponents should take care of that but I couldn’t build and test that yet.
Performance wise, there is little reason to not use RemGlk - the overhead of going from Glk to JSON is very low - and it makes debugging Glk far simpler than something like the topic we are reading ( David Fletcher’s Qt Glk
