Dear all,
I’m working on a game in Inform 6 and I’ve reached the z8 memory limit. Guess that means I need to switch to Glulx now. All I know about Glulx is that it’s a thing that exists. Is there any tutorial that tells me how to transfom my game to Glulx so that I can continue to program in Inform 6 but without the memory constraints?
Thanks and kind regards,
Grues
The short version is, add the -G
switch to your command line, and see if anything breaks. Hopefully it shouldn’t. You can use the same compiler, the same library, the same everything, just like switching from z5 to z8.
There are some things that might break, though. In particular, any inline assembly is almost certainly going to need changing, and anything where you’ve hardcoded numbers assuming a word is two bytes instead of four (to avoid that in the future, use WORDSIZE
instead).
Here’s the full story. From there:
- If you want to be (still) able to compile with Graham’s Z-code Inform compiler, you’ll need to put a small block of compatibility code at the beginning of your program.
- If you get the length of a property, with the expression (obj.#prop)/2, you should change it to (obj.#prop)/WORDSIZE.
- If you write your own DrawStatusLine() procedure, using Z-code assembly, you will have to rewrite it using Glk calls. (See the bi-platform library for sample code.)
- If you use the Inform “style” statement, you will have to rewrite it using a Glk call.
- A few new library functions are available, only when compiling for Glulx.
But as it helpfully notes:
The Advent.inf source file compiles for Glulx without any changes whatsoever.
Most of the differences only affect the library, not end-user code.
well, I think is the first time someone hits the 512k ceiling of the Z8 machine… and I agree that perhaps switching to glulx is easier and better than porting to Puny (whose should give ~36k more elbow space for .z8 story files, that is, a 512k story file should be reduced to ~476k story file)
Best regards from Italy,
dott. Piergiorgio
Probably the 64k low memory limit (or another Z-machine limitation) is the issue here, not the 512k total size limit.
(This made me curious if any have hit the 512k limit, though - it’s probably hard to create a conventional game that large without filling up low memory. Out of all the [non-blorbed] games in /if-archive/games/zcode/, I found two that seem to qualify: Heroine’s Mantle, clocking at 511.5k, and Dangerous Curves, which is exactly 512k.)
My output file is 505 kb at the moment. I’ll try Daniel’s instructions later today.
I have substituted “@set_font” for “font off/on”, but how to I substitute “@read_char”? I need it for a “Press any key” query as well as for a “(Y)es or (N)o” query. Thanks!
You can usually replace it with KeyCharPrimitive()
.
Okay, compile worked. Had to add “$MAX_PROP_TABLE_SIZE=70000” to the .bat file which now reads -
..\..\Lib\Base\Inform6 -D -G -s -v8 $MAX_ACTIONS=250 $MAX_OBJECTS=1000 $MAX_PROP_TABLE_SIZE=70000 HumanRelations +include_path=.\,..\..\Lib\Base,..\..\Lib\Contrib | more
.ulx file generated. Windows Glulxe 0.6.1.153 is installed. Problem when executing:
Glulxe fatal error: This Glulx file is too new a version to execute.
Any idea how to fix this? Thanks!!
That normally means your compiler is significantly newer than your interpreter. But in this case you have the latest version of Glulxe, from 2023. So that shouldn’t be happening.
My guess is that, since you still have the -v8
switch included (“use Z-machine version 8”), the compiler is interpreting it as “specify that we’re using version 8 of the Glulx standard”, and dutifully outputs a Glulx file with the header bytes specifying that it’s version 8. The interpreter then panics because the most recent version it knows about is version 3, and says it doesn’t know how to handle Glulx version 8.
Remove that switch and see what happens? I can’t find any documentation on the behavior of the -v
switch when compiling for Glulx (the release notes say it’s illegal!) but that’s my best guess.
Removing the -v switch worked. I should have tried that in the first place, but it seems like I behave as a coder like I behave as a player. Game starts, but the next problem seems tricky. At a specific room I get a “Glulxe fatal error: Memory access out of range (…)” error. A first search here in the forum brings up Inform 7 related problems only, and they all seem… tricky. Any ideas?
It’s mentioned in the release notes elsewhere. You can write -G -v3.1.0
to request a (minimum) version field. The line that says “incompatible with Glulx” is a mistake.
perhaps is wise evaluating if isn’t wise rendering -G and -v mutually exclusive, and changing the -G syntax in -G[version], the latter optional with a sensible default ?
only a scruple…
Best regards from Italy,
dott. Piergiorgio.
Anchorhead is a z8-file of 508k. If the only reason you need to switch up to glulx is the memory limit (you probably have lots of text, I guess?) and not any other of the z-machine limits, you can use abbreviations (if you don’t already). Anchorhead don’t use them and would free up about 80k with 96 sensible abbreviations.
If you don’t feel ready just yet to switch to glulx you could try abbreviations or some other of these compiler option space saving tricks first:
$OMIT_UNUSED_ROUTINES=1
, Really no cost. Saves a couple of kB.$ZCODE_LESS_DICT_DATA=1
, Really no cost. Saves one (unused) byte per dictionary word (~1k).$OMIT_SYMBOL_TABLE=1
. Will give you less informative runtime error messages but saves about a k.
(And also a few nitpicking points:
- The thread is a bit misnamed. Inform6 compiles both to z-machine and glulx, the switch is actually from z-machine to glulx.
- The Punyinform library is mentioned above, but I don’t think it’s possible to use that library with glulx.
)
Are you able to get a stack trace and see what in particular is causing it?
Status: With the help of Daniel I found out it’s something about some daemons I start right at the beginning. Will look into this. Thanks everyone so far!
As-is, PunyInform cannot be used to produce Glulx code as it uses quite a bit of Zcode assembly. There’s not much call for this because PunyInform’s primary purpose is for making games that run on very limited computers.