When it comes to limits in Hugo, authors are most familiar with the static limits that can be viewed or modifiable ones that can be set at compilation time. If a game needs more arrays or routines than the system default, great, we change a value and we're good to go.
There are other limits in Hugo to be aware of, though, as discovered by Robb Sherwin. More than a year ago, he noticed that some rooms defined late in the code in his WIP were not accessible. I had a chance to use the Hugo Debugger on it and could see how, for no discernible reason, the code execution would just go off the rails once it reached the applicable object. Changing the order of file inclusion made this object accessible while presumably breaking something else.
We figured at the time that some limit (besides the ones already mentioned) was being overwritten, resulting in a pocket of a corrupted code. We couldn't deduce which limit we were running into, though. It was time to consult either Kent Tessman himself or someone else well-versed with the Hugo file format. We try to not bother Kent too much, though, as creating Hugo shouldn't be a CURSE OF ENDLESS QUESTIONS. He has more important, family-providing things to attend to (buy Fade In Professional Screenwriting Software today!). Similarly, we didn't want to bother others who have already done so much for Hugo, so the issue just kind of sat for a while.
Recently, it came up again and we tried to look at the problem with fresh eyes. I pointed Robb to Juhana Leinonen's Hugo .hex file inspector page, which verified that objects were redirecting to other things.
He also brought the issue up to Kent around this time, and Kent suggested that either the dictionary or properties table was the culprit. Robb took out some words and things, and voila, everything works now.
So, the problem was solved, but I still wanted to find out what tools Hugo authors have to check for this. The issues comes down to the design of the Hugo .hex file, which allocates 64K to the dictionary, special words, array space, events, properties, and objects each. Hugo was designed to make games playable on 16-bit devices and these limits reflect that. In Robb's case, he was surpassing that 64K dictionary limit.
One of the quirky things about Hugo is that it has a lot of great features that the documentation doesn't fully explain- either their usage or the situations in which something is especially useful. Despite the fact that the compiler didn't complain about a too-big dictionary table, I figured that there must be something in there since, in my opinion, Kent really did a great job in planning for a lot of scenarios.
So before I wrote this post, I thought I'd look over the compiler switch options again (since there are several that most Hugo authors rarely use), and indeed, there is a -u switch that shows the memory usage of a compiled game.
Here is an example of a memory usage readout:
(Top: $013F44)
+-----------------+---------------+
| Text bank | $001054 bytes |
+-----------------+---------------+
| Dictionary | $0B60 bytes |
+-----------------+---------------+
| Special words | $0080 bytes |
+-----------------+---------------+
| Array space | $0CE0 bytes |
+-----------------+---------------+
| Event table | $0010 bytes |
+-----------------+---------------+
| Property table | $0680 bytes |
+-----------------+---------------+
| Object table | $0700 bytes |
+-----------------+---------------+
| Executable code | $00FB60 bytes |
+-----------------+---------------+
| Grammar table | $0D00 bytes |
+-----------------+---------------+
| Header | $0040 bytes |
+-----------------+---------------+
(Bottom: $000000)
So, the values are in hex so authors have the extra step of converting them to decimal, but hey, it can give us a general idea if we're approaching any of those table size limits.
At some point, I will probably take a look at the compiler source and see if it's within my simple capabilities to check for these limits. In the meantime, I'll probably add a page to Hugo By Example drawing attention to this. Of course, this whole issue only happens in a game with a lot of stuff so it's possible that Robb will be the only one to ever run into it!
No comments:
Post a Comment