An idea - SDL2 GLK for android, iOS, and desktop PC glulx

Technical Development Interpreters
1

Hi, I’ve done a few tiny little projects here before - I built a ncurses/glkterm-based version of the git glulx interpreter for Android, I built windows glkterm console builds, and I was an enthusiastic bystander/feature-requester when the ‘zag’ interpreter was being updated by Banbury. Apart from that I’ve not done much here, but the lack of an actually working android Glulx interpreter with graphical support is really bothering me.
I realized at some point that SDL2 has some android support. I’ve got a little C++ experience, a pretty good amount of ANSI C experience, and a bare minimum of java experience. I think I just might be ready to make a GLK implementation with SDL2 - just enough to get a somewhat more reasonable android glulx interpreter than my ncurses terminal-based binary that requires a convoluted install process and still does not support graphics or some more exotic windowing systems (I’ve had games where glkterm hangs consistently when windows are being drawn).

I don’t expect it to be amazing like iFrotz on iOS, but as twisty is proving difficult to convert into a GLK implementation it’s looking like it might be better to just start fresh. Avoiding JNI (and almost entirely ignoring java besides a basic wrapper) promises to increase reliability - I am not sure how everything will work, and it might not even be fully compliant, but I’d like to take a stab at it, using git as the underlying interpreter. A bonus to this approach is that it’s likely to be debuggable and runnable on desktop PC’s without resorting to emulation, and it will (if successful) ad to the options available for linux users that aren’t gargoyle (which I don’t care for due to the inability to disable font antialiasing and the weird build system.

I’ve got a lot of ambition but I think this may be over my head, so I’m asking for advice - anyone here have experience implementing a GLK library? Does this sound feasible? How hard was it? Am I in over my head? Is anyone with experience in SDL2 or mobile development or the GLK willing to help?

Anyway, there’s my manifesto. I hope to start on it as soon as I’ve got a source of income in real life (job hunting). Hopefully within a week.

Edit:
If I do this, I plan to release it under an MIT, BSD, or other permissive license. Maybe just public domain, even.

It’s ridiculous that android’s been around for 8 years and is the superior mobile OS from a user freedom perspective, and we still don’t have a single glulx interpreter for it. We have ScummVm, but not glulxe, for pete’s sake. We even have a 100% Java glulx interpreter (Zag) that no one’s made any effort to port to android. If I weren’t so repulsed by Java, I might have done that a long time ago myself! But after a couple of years I’m sick and tired of waiting, and of needing to bring my aging iphone everywhere I want to play a glulx game with graphics.

P.S. I just spotted this: bubblycloud.com/qglk/
Looks like it’s not quite up to date (0.7.4), but I believe ‘necessitas’ allows for QT 4 programs to be ported to android, correct? if so, I’d just need to figure out what’s chamged between GLk 0.7.0 and 0.7.4. I’m still not sure if it’s up to snuff since I’ve yet to try it on a desktop, even, butit looks like a possible alternative to starting fresh if it comes down to that. On the other hand, C++ can be the stuff of nightmares, and QT doesn’t have a normal C binding for whatever reason. I think I’d probably be better off starting fresh than trying to maintain C++ that I didn’t actually write, which scientists have shown to be a highly improbable task to successfully complete.

EDIT 2
looks like qglk doesn’t support sound, graphics,opr hyperlinks. I want to have at LEAST graphics, hyperlinks, and unicode supported. Sound matters least.

2

An overview of “what’s changed between Glk 0.7.0 and 0.7.4” is at github.com/erkyrath/glk-dev/wiki/Todo

You said you didn’t like Gargoyle, but it remains true that GarGlk is the working example of an SDL-based Glk library (SDL1). I suspect that any new SDL project would wind up reading through it a few times, if only to think about what to do differently.

3

I don’t know the status of this on Android, but perhaps something useful: github.com/weiju/zmpp2

4

Was not aware of ZMPP2.

Not tried it yet, though, and if it doesn’t support unicode and graphics it won’t make a differenct. Only gave it a quick glance so far.

It’s not java (thank god) but it’s still an OOP language, which my brain tends to have trouble with die to multiple layers of inheritance, over-abstraction, hopping through 40 files to find a data type, etc.

That’s why if I end up doing my own it won’t be in an overly complicated (from my perspective) labguage, or if it has to be, something like C++ where classes and objects are (mostly) optional.

5

That’s old stuff. Qt 5 fully supports Android and iOS now out of the box.

6

yeah, I’m aware of that, but there isn’t a QT5 glulx interpreter, is there?

I’ve never experienced anything but intense pain trying to port QT applications to the latest versions. (3 to 4, 4 to 5). This is probably largely due to my same problems with objects and inheritance.

7

Incant works and has been sitting on Github for 2 years, it runs almost all the glulx I tested with it! I must have started 30 or more glulx games on it. Only very exotic ones like Kerkerkruip don’t work at all (I wasn’t able to figure out exactly why, but Kerkerkruip seems to do a lot of exotic screen output and character input).

I did discover that Incant, tested on Android 7, seems slow compared to the same phone running Android’s Chrome running Parchment. In particular, I noticed the first couple prompts in glulx game Bronze show this. There is a pause of around 30 seconds with Incant before it’s read to play. Where running it on Android’s Chrome with Parchment the pause seems like 7 or 8 seconds. That’s a big enough difference to wonder why not just run javascript (Quixe) engine instead of this Java one. However, almost all games aren’t slow at all, and even Bronze works fine after the startup pause. But, no way can it run Counterfeit Monkey (multi-minute startup and stalls between prompts). Bronze is far more reasonable as a test game that does a lot of processing on startup (answer “no” at the “Have you played interactive fiction before?” to go the slower code path).

I just wanted to make the case that Incant is in very good shape and is all native Android. It probably needs a new front-end for loading games (right now it tries to scrape websites with regex and the code is 2 years old and mostly broken). But, once given a glulx download it knows how to process and run them well that I can find. Complex games like Rover’s Day Out seem to work well!

8

Do you have source / build instructions for this? I’m trying to reference the same thing. Thank you.

9

There is a somewhat-working SDL1.2 Glk out there, I managed to get it to compile on Ubuntu 16.04/16.10 x84! It’s called ‘nanoglk’. https://intfiction.org/t/new-glk-implementation-nanoglk-based-on-sdl/3641/1

I put the source code up on github.com/BroadcastGames/nanoglk with my hacked up Makefile I needed to get it to build on Ubuntu 16.10.

Finish this up for SDL1.2 and then making a conversion to SDL2 could be an option?

10

5 days after finding nanoglk, I’ve put in 25 hours of work and reading on it with my miserable C coding. I’d rather work in assembler :wink: I managed to get both apathy and rejection out of the SDL community asking for someone to port the nanoglk SDL1.2 open source code to SDL2. I hacked on it myself for 23 hours and another 2 hours spent asking for help from those who had experience doing porting.

Excuse mistakes, but this is what I think I learned

  1. SDL_Surface is the entire screen of SDL1.2 and in SDL2 the new design is that you move to SDL_Window to allow for multiple desktop windows and also to run SDL_Texture objects on the GPU instead of on the main CPU.
  2. SDL2 has a cheat mode to use a single surface of a Window (and you can still do multiple windows and other advantages over SDL1.2). This is frowned upon but fit the existing code. I spent the first 15 hours trying to avoid using this ‘dirty design method’ and attempted to do things the proper way in reworking the old 2012 code with SDL_Renderer but ran into too much confusion over how to make it work. The source is on github at about 70% complete in one branch.
  3. I started over with the SDL2 approach of having one SDL_Surface per SDL_Window. This worked except I ran into some kind of problem when multiple windows. I’d say this was 90% complete port of the code and I just can’t figure out why it is behaving different from the SDL1.2 branch of code. Help is welcome! The story Anchorhead demonstrates the problem. Simple one-window stories like Adventure work great on the new SDL2 port.
  4. Even after using SDL2 for output and input, Unicode font problems persist on nanoglk SDL1.2 and SDL2. Same as I experienced with Gargoyle GLK. Unbutu 16.04 and 16.10 both don’t show unicode correctly that the same systems running Inform 7 IDE built-in git/guluxe show unicode fine!

It was after investing this much time I realized two key things: there were no SDL2 examples of how to emulate a ‘terminal’ that scrolls. And nanoglk has no ability to scroll the window back or copy/paste the content. It’s ideal for a 32MB of RAM and 300Mhz MIPS processor of year 2010 (about $6 in hardware) that it runs on, but it lacks what I really was hoping to find in a C code for Android. I need a scrolling Window and nanoglk’s design is to treat the screen as one large bitmap (framebuffer) to slice and dice pixels from. I still welcome a scrolling SDL2 example window for text that ideally supports copy/paste and such… but I’ve gone too far beyond my understanding and reached problems I can’t solve. This is a different branch on github.

So I have two branches on github, both failures of conversion from SDL1.2 to SDL2.

Now I’ve come to realize that I truly want to decouple the output rendering/resizing/scrolling from the C code more. So, I made a post about a fresh approach with ‘glkhtml’ library. However, my messy and recent code for SDL2 is here if anyone wants to take a stab at it. I wish I had solved the final problems of lost content that anchor.z8 revealed. But I need I workable SDL2 example of a scrolling terminal and all I’ve done is irritate people and get people who say they want paid money to make such example code.

11

Some positive news: I found that a non-Glk implementation of SDL2 has been done in recent months for Fizmo! fizmo.spellbreaker.org/changelog - this may very well hold SDL2 examples for how to properly implement the scrolling screen (Terminal like) that had me stuck. Useful reference for nanoglk development.