After several (tiring) days, I’ve gotten iOS Glulxe up to the same state iOS Fizmo is at. You can build an iOS app for a Glulx game.
Somebody hug this man, please.
Amazing, thank you!
Incidental details:
This involved quite a few additions to the glulxe source code, but they’re all hooks or callouts that are invoked only by the iOS interpreter. The behavior of glulxe on other platforms should not change.
I will eventually make this a new glulxe 0.5.0 release. At the moment all this work is sitting in a branch.
This work allows an interpreter to perform a save while the game is awaiting input (rather than the usual situation, when the player types “save” and hits the @save opcode). Then the interpreter can restore at launch time (rather than on the @restore opcode). This was a minor nuisance in Z-code, but it turns out to be a major nuisance in Glulx, because I’ve shifted so much of the I/O responsibility from the interpreter to the game. Oops. It turns out that I need to store the state of all the Glk objects (windows, streams) in the save file – normal Glulx saves don’t have this.
As a bonus, when you launch the app, you get all your scrollback visible from your last session.
(I took the same path with iOS Fizmo (saving all the Glk state for launch time) but there it was for UI polish, not by necessity. But hey – I had that much of the code ready for iOS Glulxe.)
Other Glk libraries can add this serialization feature, if they want to support autosave/autorestore. I do not intend to add it to cheapglk or glkterm, because, as noted, it’s a major nuisance. I also don’t intend to spec this or standardize the Glk-serialization format. (iOS Glk uses the standard Cocoa NSKeyedArchiver, which not easily readable outside the iOS/Mac world.) The point of this feature is to allow frictionless task-switching on a single device. If you want to transfer portable save files between devices, use the normal save files created by the “save” command.