I am running into an odd problem for my EctoComp 2016 release. It’s at 3ff40 memory when I build it in the Inform IDE and use the supremely handy
Include (- Switches z; -) after “ICL Commands” in “Output.i6t”
and see the error progress. So, just under 40000. Great!
But I want to add a couple features.
When I build in release it’s at 34000 so I have a lot of space there. And I’ve tried to compact my code but I’m out of ways to do it.
So my question is, what are the known risks of building and debugging in z8, then releasing as z5? Obviously it’d be a good idea to test the z5 binary and have someone else, too, but before any major coding I’m wondering if I’m doing/missing something drastically wrong, or if this is a legitimate workaround.
I’d like the game to remain a z5 on release, but I’m not emotionally attached to it being so. But I am curious, if anyone can help.
It should be noted that, while z5 and z8 are functionally identical, they aren’t binary-compatible. (High-memory addresses in Z-code are stored as 16-bit values multiplied by a packing number; for z5, that’s 4, but for z8, it’s 8. See Z-Machine Standard 1.1 §1.2.3.)
This means that you can’t simply rename a z8 file to z5 and expect it to work on interpreters that only support z5. If you want to release z5 files, you need a compiler that natively supports z5 (like Inform 6, or older versions of Inform 7, which is what I assume ashultz is using). In theory it should be possible to convert between z8 and z5 after the fact, as long as the file is under 256 kb, but I’ve never tried (ztools?)
That would require knowing what values in the compiled code are packed addresses, which is impossible in theory. ztools catches most of them but not all.