goods news, bad news

So, after some more playing, it turns out that the game I was testing the 16-bit interpreter with, the Vault of Hugo, won't restart even if you only use the standard library (also, a small Roodylib game will still restart in the 16-bit interpreter). If I drop the HugoFix debugging suite and identical and plural object support from Vault of Hugo, the game will work, but add either one of those and it's back to shenanigans. I take this to mean that the issue is deeper than anything I can do to fix.

For the most part, not being able to provide games for the 16-bit interpreters isn't a big loss. It'd really only be useful for things like the @ party thing mentioned in the last post (although it's still very possible that IF doesn't even need to meet the 1992 requirement) or targeting other real die-hard retro fans.

When I do the @ party thing, I'd like to go somewhat hardcore. I think that means that I'll probably have to use ZIL for that, which is cool, but my only regret is that it's probably too late this year for me to write a ZIL game in time for @ party. Still, next year, the @ party might be a great thing for a ZIL competition to piggyback on to.

using what I've learned

First off, hey, this is the 70th post of this blog. Not bad for something less than a year old, I think. Just goes to show how geeky I can be about taking apart an IF language!

Anyhow, I had been thinking that of all of my extensions, my NPC  pathfinding extension "findpath.h" probably had the most bad code, memory-wise, as it assigns every room two additional properties, which it clears between uses. That is not unlike my array-clearing code that caused that huge headache in Roodylib.

It's always interesting to look at code you wrote a year ago, as I found several parts of "findpath.h" useless. Among the changes:

• Previously, before writing the directions to be taken to the applicable character's script, I stored it in a property for that character (something that I was replacing the whole character class to give each character enough open slots). Since the code only sets up one path at a time, I figured I could just store the steps in a regular array that all characters would use. I think I wrote the original code at a time that I was especially fond of property arrays.
• The code used an included routine called PropertyCount that went through the given property array and counted how many elements had values. Now, this might still be useful somewhere, but the way my code used it, I found I could easily replace it with better usage of local variables. I also clipped some of my determining-which-exit-is-best code by using local variables better.
• Instead of clearing the room properties, I now determine whether or not a room has been counted yet by using the already_listed attribute. I can't say for certain, but I thought there was a chance that using an attribute might leave a smaller memory footprint.
• I replaced this finding-the-other-side-of-this-door-object code:
  

          if InList(a.d, between, a ) = 1
              a = (a.d).between #2
          else
              a = (a.d).between

  With this code:
  

          a = ((a.d).between #((a = a.d.between # 1) + 1))  

   Anyhow, that second thing, which I got off of CharMove or somewhere, might take a bit longer to read, but it does the same thing without having to call InList. Now, I don't know if calling InList really uses that much more processing power or memory or anything, but at least, when you are using the debugger, you won't have to step through those extra lines.
  
  So, all in all, findpath.h is a leaner, meaner machine now. It still has some of the same hang-ups. Like, it doesn't have awesome code for dealing with locked doors or anything, but even with that, I think I put it in a much more stable place (now, if there is no available path to the "prize", the code should shut down without printing anything embarrassing).
  
  So yeah, there's that. If you are curious about the two versions, the old version is http://roody.gerynarsabode.org/hbe/findpathold.h and the new version is http://roody.gerynarsabode.org/hbe/findpath.zip.
  
  Happy pathfinding!
  

straight from the Hugo source

So I asked Kent Tessman about exactly what was going wrong when something like my ClearArray routine uses up all of the UNDO memory. He answered:

The way Hugo's undo currently works, it stores a stack of individual commands, and basically sticks a bookmark in where a player command would be. Sorry, but the first 'individual commands' I mean 'program statements' or 'program commands'. So when you assign a variable or -- as you discovered, a single array element -- it uses an undo slot. Now, there are lots of them, but the default (and essentially at this point standard) engine has an arbitrary limit to keep memory usage down.

So that'll be an interesting thing to keep in mind in the future. I then asked him if, memory-wise, array elements, variables, and property elements- and the setting of- are interchangeable. He answered:

For the most part.  I mean, basically what Hugo does is allocate a big chunk of bytes, and divvies it up.

 So I think the lesson to be learned from that is to not put all of your state-tracking changes in one basket but to split them up between arrays, property arrays, and variables. Whatever the case, most importantly, don't write code that sets many of these values needlessly.

Anyhow, I'll try to have a new version of Roodylib up soon.

worst case scenario

Grrr, so annoyed. While testing out that fuses code today, I noticed that games compiled with recent versions of Roodylib don't have enough memory for even one UNDO. Truth be told, I often test new code with Gargoyle since the Gargoyle window is so unobtrusive, but Gargoyle's UNDO buffer is so small that I probably didn't blink twice when newly compiled games were unable to compile.

Testing now with Hugor, Roodylib has been short on UNDO memory since before I started uploading to bitbucket (and definitely before the 3.0 release I uploaded to the IF Archive).

The good news is, getting rid of just one for loop called by PrintStatusLine freed up space for one UNDO, and compiling without my new fuse code frees up memory for even more.

The bad news is, now I need to go through all of Roodylib with a particular eye for optimization. Having games unable to UNDO is unacceptable. I've long been worried that I'd run into this problem, but it is quite annoying to have to deal with it.

My optimization strategy will consist of cutting any loops that I can and making sure that the others are as concise as possible. Beyond that, I've long been suspicious that Perform doesn't need to call SetUpDirectionObjects every time, and I think I'll see if I can move it somewhere else.