I thought my game was pretty small, but it’s only minimally fleshed out and it already doesn’t fit into z8. Even after trimming out all the friendly grammar and most scenery items, component parts, and nonessential properties, it’s still 6K over the limit. Is I7 a glulx-only language for all but the most minimal implementations, or am I just writing sloppy memory-hogging code?
I remember being impressed by the tremendous size of Curses, and that fit into z5. Perhaps grammar has become more advanced and memory-intensive since then, but it just seems weird for a game with 130 objects to be too big for z8.
I have a pretty large number of rules, and of course lots of text. Is there any sort of guideline for figuring out where the memory goes? Is there a runtime memory-mapping tool? I thought I heard about one but I can’t remember where. At some point I thought I saw an error message promising to give a memory map, but there was none.
One thing I was wondering about was creating kinds vs. creating properties. If you have a property that can only belong to a small set of objects, it seems to make sense to create a kind. But if I’m not mistaken, I7 creates a kind-index property for every kind, and if a kind inherits from other kinds, it has a kind-index property for every single kind that it inherits from.
So if you have this:
A subject is a kind of thing. A subject has an object called the concern.
You’ve created two properties: The subject-index property and the concern property.
On the other hand, this:
A subject is a kind of thing. A prayer is a kind of subject. A prayer has an object called the concern.
…looks like you’re being more focused, but if you don’t have a lot of subjects, it might not help: In fact, you’ve created three properties, the subject-index, the prayer-index, and the concern.
Does that make a difference? When does it make sense to give properties to a few extra things instead of creating a new kind?
Compiling source code can be more or less memory saving, depending on the compiler.
Complex code structures can be broken down to spaghetti code. IF-THEN going through hardcoded variables consumes far less memory than tables and lists.
I trimmed a bit more and got it to fit. But it’s not finished, so I don’t know how long that will last. Also, I haven’t really tested the trimmed version.
This parses the “gameinfo.dbg” debug file generated during an Inform compile. It can also compare two different gameinfo.dbg files, which is the real value. Compile your I7 game, copy the gameinfo.dbg file somewhere, chop out or add a feature, compile again, and run the script to compare the memory usage. You can get a list of every array that’s been added, removed, grown, or shrunk – hopefully that’s enough to let you locate important changes.
(If you have an I7 project called “Foo.inform”, you can find this file after a build in the location “Foo.inform/Build/gameinfo.dbg”. You may want to turn off the “Clean build files before closing” preference, so that this file sticks around after you quit I7. If you’re using I6, include the “-k” switch when you compile.)
Read the comments at the top of the file for full documentation.
(bytes) (code section)
192 abbreviations table
272 actions table
7878 adjectives table
30738 array space
1642 class numbers
349232 code area
10938 common properties
0 dictionary
480 global variables
2583 grammar table
8 header extension
5101 individual properties
2478 object tree
2 parsing routines
126 property defaults
??? strings area
That’s what I was afraid of - too many rules and phrases. But why is the strings area unspecified? And the dictionary empty?
When you say “6k over the limit”, are you talking about RAM (the Z-machine’s 64k limit) or static memory (512k)? If it’s the latter, then text or code must be the problem – you don’t need an analyzer to tell you that.
Static memory - I get the “Packaging Up for Release - Ran out of Space” error, with the message in the Progress saying “The story file exceeds version-8 limit (512K) by X bytes.”
Sorry for being lazy - I’ve read the docstring now. The analyzer is measuring static memory usage, right?
It’s really just parsing as much data as I can parse out of the I6 debug output. I had it focus on array usage because that’s the biggest component of the 64k limit, and that’s what most people hit first. So this script is not as useful to you as I’d hoped.
I could update it to list every I6 function and how large it is (as compiled code). It would be a big list, though, and most of the function names wouldn’t be enlightening. (R_800, R_801, R_802…)
Based on a script consisting of “Include X/Test is a room,” the largest extension I’m using is Conversation Responses by Eric Eve, which results in a total size of 207360 bytes (as opposed to 19200 for “Test is a room”).
To test how Conversation Responses scales, I tried a baseline of “There are 20 rooms. There are 100 things.” (204800 bytes) and then added the inclusion: 219648 bytes. So at the approximate size of my game, the extension adds about 14K. Doesn’t seem like that much to worry about.
My immediate reason was because Juhana hadn’t yet released her Parchment-Transcript tool for glulx. Now that she’s done that, it’s not so pressing, but I’d also like it for portability and a sense that I’m doing my job as a programmer. I think I will probably abandon it, at least for now, but I might still try to release a pared-down z8 version along with the glulx version.
