This post is going to be boring. You don’t have to read it unless you want to use obscure I6 compiler options.
Back in 1998-ish, when I was defining the object record layout for Glulx Inform (I6), I threw in seven bytes for the attribute flags. (That is, 56 attributes available.) This was more than Z-code had (48 attributes in V5/8) so I figured it was good.
But I didn’t want to absolutely lock that number in. So I added a compiler option. You can say ‘$NUM_ATTR_BYTES=11’ on your I6 compile, and it will leave room for 88 attributes. The value has to be 4n+3, because of the way I laid out the object fields, but you can increase it as high as you want.
So fine. Only I screwed up. I forgot to make the veneer code adapt to different NUM_ATTR_BYTES values. (The veneer code is a set of routines generated by the I6 compiler which handle object access and property lookup and so on.) So if you tried to use ‘$NUM_ATTR_BYTES=11’ in a game, all the object access would look in the wrong place and your game would crash. Oops. You’d think I would have noticed this in testing, but apparently not.
Anyhow, I submitted a compiler patch last week, and fixed the veneer code. (The I6 library code doesn’t need to be fixed, fortunately.) That hasn’t been released yet but you can get it on github if you really want.
So fine. Only I screwed up worse.
Back in 2006-ish, I came up with a scheme to speed up Glulx games by moving a few core functions into the interpreter. And one of these, you guessed it, was a veneer routine that contained the NUM_ATTR_BYTES bug. It’s fine as long as you stick to the default value of 56 attributes, but as soon as you increase it, the game crashes. And this is a bug in the interpreter. I can make a game using spiffy new compiler features but I can’t make players upgrade buggy interpreters.
Current plan: leave the old accelerated routines in the interpreter – I did promise that they would never change – and instead add a new set of accelerated routines, which are NUM_ATTR_BYTES-aware. The new routines will behave exactly the same as the old ones in the default case, but if you increase NUM_ATTR_BYTES, they won’t crash.
(The annoying part is that the bug is only in a single routine… but all the others call it, so I have to replace the lot.)
If you build a game to use the new routines, and run it on an old interpreter, it’ll run slow. (Because the new acceleration routines are missing.) This is better than crashing but obviously not ideal.
Note: I7 games use the (old) acceleration routines. I7 games never need to increase NUM_ATTR_BYTES, so they can ignore this whole problem.
Someday we may see the I7 compiler increasing NUM_ATTR_BYTES so that it can make more efficient use of Glulx RAM (I won’t get into the details) but I’m not going to put that forward as a suggestion until we get updated interpreters into common use.