Several months ago (in email), there was a discussion about avoiding very slow startup procedures for Inform games. (E.g., Reliques of Tolti-Aph burns bazillions of Glulx CPU cycles in “when play begins” code.)
It would be nice if the I7 compiler could just compile a game file in already-started-up form, but this is difficult for a bunch of reasons.
In unrelated work (also several months ago), I added a Glk facility to store a data chunk in the Blorb file for the game’s use. (github.com/erkyrath/glk-dev/wik … ec-changes) It recently occurred to me that this could be used to solve the startup problem.
Plan: when the game starts up, it tries to open a data chunk with a conventional number. If that chunk is present and nonempty, the game assumes it’s a save file and restores it. The save file contains the game in fully-started-up mode and it can continue from there.
But where does this save data come from? Here’s the clever bit: when the game starts up, if it sees that data chunk exists but is empty, it assumes the author wants the save file written out. So it runs the (slow) startup code, gets itself in position, and then writes out “autorestore.glkdata” as a save file.
If the data chunk doesn’t exist at all, or if the interpreter doesn’t support the Glk data feature, the game ignores all the fancy stuff and just runs the (slow) startup code and gets on with the game.
So the author compiles the game, blorbs it up with a zero-length data chunk, and runs it. There is now an autorestore save file ready to do. The author then blorbs the game up again, replacing the zero-length chunk with this new save data. This is a hassle (and you have to repeat it every time you recompile your game, because you need the save data to be compatible). But it’s easily scriptable.
The nice thing about this plan is that it doesn’t require any updates to the Glulx spec, the Glk spec, or Glulx interpreters. It works entirely in game code. It’s backwards-compatible to old interpreters, too.
So I went to implement a proof-of-concept, and I ran into the snag. (Anybody want to guess? No?)
Glulx save files are Quetzal-based, which means they’re IFF form objects. Blorb files are also IFF form objects. When you embed one IFF form in another, you’re supposed to leave off the inner file’s header. (Because the IFF embedding wrapper is an inner header, basically. This has long been a source of confusion for embedded AIFF files.)
Unfortunately the Glulx interpreter’s restore code gets all confused by this. So my proof-of-concept code fails.
Possible solutions:
(a) Make the interpreter smarter about this. (Requires an interpreter update.)
(b) Shove the save data in there with a double header. (Requires updates to Blorb tools, at least the ones which are trying to be correct about IFF embedding.)
© Prepend a padding byte (or four) to the beginning of the save data. Now it doesn’t look like an IFF file any more, so Blorb tools will shove it in there as raw data.
(d) Make the Glk data-chunk call smarter. That is, we could decide that I screwed up by making that header inaccessible – you’d run into the same problem if the game wanted to read AIFF data out of a Blorb chunk. The fix would be to add an optional flag saying “give me the damn header, if there happens to be one.” (Requires a Glk library update.)
Thoughts? I lean towards © if we want to do this fast and dirty, (d) if there’s time to do it right.