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!