Tilting at Windmills

My work at converting the dialogue system to sectors instead of records is complete! Now all incidental text for a given set of mobs is stored with the mobs themselves, and transaction text is with the transaction codes.

Effectively, you only need three pieces of data and a sizable buffer space to do variable-length records in a sector system: The base sector to start in, an offset value in that first sector to start your data at, and a number of sectors to read. In my case, my VDP file buffer has a maximum size of 4K, which is 16 sectors. More than adequate for my needs, it fits neatly in a single page of AMS memory, and I can bit-pack the sector count as a nybble (4-bits) and use a single word to store both a base sector and sector count.

I tested it on the hardware tonight and it was VERY fast… loading a map or transaction takes a few seconds, but after that it doesn’t have to refer to the disk at all and pretty much generates the text instantly.

Onward with the bug fixing… At this point, I don’t think I’ll have combat ready in time for Fest West. But I think I can get most of travel and management done. We’ll see…

Gotten quite a bit of ground covered since my last post… All the bugs I first encountered are fixed, but there’s plenty more to deal with. 🙂

I took a brief side-trek to write myself some console applications in C# to help with my work. My original method of compiling the game was as follows:

1. Build each module source using A99, creating an object file
2. Using Classic99, load the object file into memory, then dump the memory into a binary file
3. Copy the memory sections with program data into my program file where they are loaded from

Not TOO bad, but I was quickly running into annoying problems, like anytime I changed code significantly in the root module, I had to also build the start module or things stopped working there. (Because addresses were offset from expected values.) And the fact I had to navigate with the mouse to do loading and debugging in Classic99 slowed me down quite a bit too.

Fortunately, Mike Brent helped out by sending me a simple object to binary program he’d thrown together. I was able to adapt it into a new binary for my purposes that translated the object file into a straight binary file, removing the need for Classic99 in the process entirely.

Then I wrote another console app that did binary copying from one file to another, only requiring you to supply base addresses in both files and a length. That lets me copy the resultant binaries into my program file directly. So now I can compile, build and create the program file all by clicking a single button!

Right now I’m debugging the statistic screens. I discovered that I hadn’t populated real values for item data at all, so that was my first fix. Besides that, mob movement seems weird; my monsters aren’t chasing me and they’re moving across water and other “inaccessible” tiles.

All you can do is just deal with each problem one at a time. Sooner or later you WILL fix them all.

Continuing my work on the combat module, and finishing up the start module! Some updates…

While studying a hex dump of Castle of Tharrogad for the Color Computer 3, I noticed an interesting data pattern… All the text strings had a curious high-value ASCII character at the end instead of the expected letter. I realized that they were using the topmost bit as an end-of-line indicator.

Most “strings” in assembly either use a length value (A byte typically, which means your string can be a maximum of 255 characters) or a null terminator at the end of the string. (typically a 0-byte) In the case of both methods, every string takes up it’s characters in memory + 1. But with a bit-delimited method, it takes up exactly it’s size!

Now you may ask, quite fairly, what does one byte per string matter? Even on a vintage system it’s not THAT much. But in practice, I found I was wasting a lot of instructions to populate the necessary registers to write text to screen. Plus, using the standard multiple byte write routine, you would have to push the length byte into a register then shift it to make it a word value, resulting in burning six bytes of instruction space for EVERY text string.

I wrote a specific text-to-video routine which looks for that bit, and only stops writing when it encounters it. It also can move through entire blocks of sequential text, so that I can only set two values (screen address and text address) at the start, and just change the screen pointer for the rest! The result is my interfaces can be built much more efficiently in memory without a great deal of trade off in performance.

I also made some adjustments so that I could start using compressed text in memory for the Start module. This became necessary as raw uncompressed text pushed the module size to close to the limit. I reclaimed over 2K in space by using compression and the natural text block writing system the game natively uses.

For the battlemap work, after writing out various designs and trying different edge cases, I think I finally hit upon a workable method. Here’s how it will work…

A few years back, I wrote a TI-BASIC game called Aperture, a simple version of Portal. (Which you can find on the TI Game Shelf.) It features 16 different levels with a wide variety of features. How did I do it? I used a procedural generation process, storing different drawing operations such as horizontal line, vertical line, box, and so forth, as well as placement of special objects. Each level took up a couple hundred bytes of dataspace on average; the more complex the level design the more it took.

I realized that this kind of system would work for battlemaps too. When you want to draw features in a two-dimensional format, you’ll find most linear compression methods are very binary; either they are fantastically good or extremely inefficient. This defeats that making the complexity of the screen the only limitation.

The design is as follows:

• Each tile has a “code” indicating it’s general type such as grass, hills, forest, and so forth
• Up to 16 character patterns are loaded from memory for the battlemap, some are indicated as “open” spaces and others as “blocked”
• The various patterns (relatively stored as 0-15) are drawn and plotted. Some methods will scatter patterns at random
• If you have blocking tiles surrounding the player, these tiles are used to draw “walls” for dungeon and building corridors
• For each map, a common “wall” and “floor” are stored in the map array data in the event that it can’t determine an exact type

My rough calculations right now show that I should be able to store all the battlemap generation data in around 1 kilobyte. That should be workable!