Do-Over Dialogue

So… I need to re-engineer my file system for dialogue.

I hadn’t loaded the current game executable on my actual TI in awhile, so I decided to try, mainly to make sure I hadn’t introduced any problems. Initially I had to fix my file creation tools to make sure sectors were padded out properly; TI99Dir wasn’t happy with incomplete sectors when copying to disk images.

After that, the game ran well… until I reached my first bit of dialogue. Quick pause as it accesses the disk, and a single message pops up. Okay, not too bad. Go to my first complex conversation… and it’s literally taking 2-4 seconds to load EACH LINE OF TEXT. Including your dialogue options, which pop in like snails one after the other.

It’s my own fault, because I forgot a critical fact. Limit your single file accesses as much as possible. The overhead of opening, reading, and closing a file is not too bad if you do it once, but if you’ve designed a system that requires constant access to different files, you got a problem.

My first thought was, why not pre-fetch all dialogue for transactions? Well, no, that won’t work. It would STILL have to access each individual record, which means you’d offload the sluggishness to the beginning.

The answer is simpler than that… don’t store dialogue in separate files. Store it WITH the pertinent data you’re loading. Then you only do an open/read/close operation once. As long as you have the buffer space for it, you can read in all the data at once. CPU memory is NO concern with the AMS, I can earmark pages to store data.

This means abandoning the record file system and using direct sector access as well. So I’ll need to re-write my content tools to generate tight and compacted sectors of data with offset values and delimiters. It will be a LOT of work to re-write but the end result should be a much better experience on the actual hardware.

It also makes me realize my original non-AMS design, which relied heavily on off-loading data to disk, even things like item names, would have ran like a snail in Doc Martens on the actual hardware. I’d have been so disappointed and frustrated if I’d continued down that path!

Some disadvantages is I lose the ability to avoid duplicate text. Your common dialogue options, for example, will either have to be replicated in every data block, or I will need to consider a “common/custom” system so it can read options from memory for common ones (Buy, Sell, Leave, etc.) and from the data block for custom ones.

The other problem is waste space has the potential to be worse; I may end up with a lot of unused bytes in a given sector because I simply don’t have anything to fit in there. I think I already had a lot of waste though in the current file system, so it may not be too bad. I won’t know until I assemble a new model and see how the numbers look.

Finally, one particular data set (mobs) will require me to save the data BACK to disk. That means preserving the original sector data for saving. Mostly house cleaning concerns, although if my mob files get larger due to storing text data, it may push them beyond the game disk’s size. I may have to abandon the idea of making the game work with 180K DSSD disks and go right to 360K required.

Best roll up the sleeves and get to it then…