Bits and Battlemaps

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!

Posted in Coding, CRPG, Design, TI-99/4a | Leave a comment

A Preview

A new video… the title screen with music!

Work on the combat module is proceeding slowly… I have to solve the battlemap generation problem, which is a totally new design.

I also did some clean-up work with my external tools. I originally had allΒ  my graphic sets in separate files that were loaded individually into memory. Since they are now part of the program file for the entire game, it made sense to update my tools to just read/write from that file directly. Same thing with the title screen as well. Then any changes made are immediately in game to without having to copy and paste hex data. πŸ™‚


Posted in Coding, CRPG, Design, Graphics, TI-99/4a, Video | 4 Comments

Mischief Managed

The manager module is code complete! And with about a kilobyte to spare…

I suppose I shouldn’t be too surprised it managed to take up nearly 12k… building interfaces and controls is by far the most expensive operation in any application. I ended up moving party re-ordering into the travel module. I had originally envisioned a separate page with animation and stuff, but I was able to build something much cheaper in memory and simpler in design.

A lot of the interface focused on only permitting options that were doable. A good example is equiping items. The interface requires you to remove items before it lets you equip something new in the same slot. Why? Because if you had, for example, a 1 handed weapon and shield in the offhand, equiping a two-handed weapon drops two items into your backpack, not one, and if a player had no space for the additional item, it would get lost, or cause an error of some kind.

Another example, if the item in question isn’t usable by the class, you’re not even given the option to equip it. The same goes for trading items. If you’re in a solo party, you can’t give anything away. If it’s a two-man party, your trading partner is obvious.

Next phase, combat! This will be interesting, besides reclaiming and rectifying the older code base, I also have some new code to write:

  • Generate character set graphics dynamically for each map
  • Generate battlemaps dynamically for each battle based on underlying terrain
  • Allow for multiple monster types for different stats
  • Allow for large monster types that occupy four squares instead of one, and must be targetable as a single entity

Cry havoc… πŸ˜‰

Posted in Coding, CRPG, TI-99/4a | Leave a comment

Manager Mayhem

A short update, work is continuing but more slowly due to real life…

For starters, I attended a convention in Portland last week, which was a lot of fun!

Unfortunately, I managed to pick up an ear infection in the last couple weeks that’s been slowing me down, both on hobby time and at work. I’m on antibiotics now so hopefully that will nip it in the bud soon.

The manager module is filling up fast, I only have around 2K and change left. I’ve decided to cut a feature, which was in-game storage of items, which would have been facilitated at various buildings in the major cities.

The problem is that the amount of code necessary to build and control an interface is significant. I have to complete the critically necessary components (like party management and player inventory control) before I can think about adding bells and whistles. In fact, that’s more the kind of feature that would come out of play-testing, if item management proves to be a problem.

After all the major game code is complete I may be able to move about/juggle some specific features into different modules and add new ones. The travel module has space to burn, potentially. (Although I am still not sure where the End Game code will go…)

The CRPG Addict has been playing an older game “Deathlord” recently, and having a very frustrating time of it. You can read his latest post about it here. It illustrates the importance of not just completing a game, but designing it well. A good game is like a good story; pacing is everything.

On the side, I’ve also been writing and re-writing portions of the content on the later disks. My early maps and places definitely have had the most time spent on them, and the latter not as much. A particular concern for me is to avoid repetition; having the same kind of character, story arc, or quest elsewhere is not all that fun. Tying it all together and making it a cohesive whole is paramount.

Posted in Blog, CRPG, Personal, TI-99/4a | 3 Comments

Happy New Year

Happy 2018 everyone!

I didn’t get quite as much done as I’d hoped, but I did make some significant progress on the CRPG.

I finally finished the title screen! I may still go back and tweak it a bit later, but right now it looks good enough to ship with if needed.

I also completed the musical opening, although I still need to integrate it into the program. I’m still going to do some work there as well; there’s a bug where after the song is completed there is a last little “bing” of notes from a source unknown. I also want to soften the volume on it; it’s rather loud on the hardware even with the P.E. Box on.

Code-wise, I completed the Travel module, all that remains is the sailing portion which is tied into the manager module. I’ll no doubt have many bugs and issues to work through once I run it, but at least it’s code complete and it compiles without error.

The manager module is a bit of work, because I’m throwing out most of what I’d done previously and starting fresh. For statistics screens, I originally loaded screens from disk and then populated them with values. This time around, I’m generating the screens completely in code. (Yes, I COULD store them complete screens in memory, but see below on that.)

I’m hoping that transaction code will remain mostly the same with just some tweaks. I figure I have at least a couple multi-hour sessions ahead before I can call the Manager module code complete.

My goal is to keep the program file, which is loaded in chunks into the extended memory, at 128K. This is to keep the base disk size for the entire program at 180K, because there are still a LOT of 99’ers who lack disk controllers capable of more than that. Disk controllers are mostly TI on eBay these days, and if you don’t get an 80-track modification done to them they’re limited to 180k.

Posted in Coding, CRPG, Screenshots, TI-99/4a | 9 Comments

Holiday Resolutions

Happy Holidays everyone!

Working hard on the CRPG… I intend to have the game at least in a running state (not bug-free necessarily) by the end of this year. Hopefully that means I can start taking screen shots and posting videos as well!

I finally sat down and wrote a music player. It’s a little different then doing sound effects, and requires a lot of calculation to be able to have it play a “song” in a good way, but it’s going well! I may even have the music complete before the title screen.

Fest West 2018 is on April 28th, I definitely want to be able to show something cool by then.

Posted in Blog, CRPG, Personal, TI-99/4a | 4 Comments

Hardware Hassles

Been a busy holiday weekend… My company, while in software, is also in retail so they wanted coverage during the entire five-day holiday shopping period to make sure nothing went wrong. I ended up doing a couple of very early morning shifts on site and a few virtual ones. I also managed to catch a cold, bleh…

As far as CRPG work goes, I’ve been wrestling with some concerning issues with the game itself. I decided to port my code over to the hardware to test out, and it failed to work. First the loader just failed to load any of the game data, then later it was loading but mysteriously omitting part of the data. (The title screen, in particular.)

I was reading schematics, writing test programs, and analyzing everything (disk controller, memory card) to try and determine where the failure was for the last several days. Upgrading my laptop with a new hard drive and memory, where I do most of the PC side work, complicated matters as well.

I FINALLY sussed it out today… The disk image used by the Lotharek drive was flawed. How it got messed up I’ve no idea, but on hardware it failed to load files correctly. Mysteriously, disk catalog systems showed all the files correctly, and they appeared to be correct in hex code. Initially it seemed like any new disk image I created wasn’t working, but a complete restart of the directory program cleaned everything up.

Part of me is furious at wasting several days trying to figure out the issue… The other part is relieved there is no issue with my code or the other hardware! I was being careful to make sure that any hardware requirements were met.

Re-writing the game to make use of the expanded memory has been good for making better code and making better use of what’s available on the system. I figured out how to use the “read/write files by sectors” disk operation which is used for both loading the program data into memory pages (128k worth) and to copy and overwrite saved game files to prepare a new game. A lot of my old infrastructure code for file management is getting removed and re-written since I’ve cut down file usage considerably. I also ended up removing the idea of “disk paths”, the native TI disk system uses a number or letter designation for a drive, which the best 3rd party extensions (like the Horizon RAMDisk) just extended rather than replacing. I’ve decided to make the game just expect the game disk to always be in the first drive (DSK1) rather than have it be clever and identify it’s origin disk on load. If I get a LOT of push-back I may add that back in.

I’ve also decided I’d better start sharing a progress list. It always feels good to check things off a list! I’m working on one module at a time, and adding common functionality to the root module as I go along. For example, base file management is in root, but each module would have individual file controls for specific data types.

You can find my progress list on the tabs for the main page!

Posted in Coding, CRPG, Design, TI-99/4a | 2 Comments

Picture Perfect

The work continues… I absolutely intend for this game to be finished and complete in 2018. It’s amazing how many different pieces and parts need to be completed though to make that happen.

Right now, I’m working on something I’ve been doing off and on since the start of the project, the opening title screen (with music) and the interface for creating new games. The code has never been written so it’s a new fresh thing to do, and it’s helping me sort out which functions need to be in the “root” module.

The title screen however, I’ve had a prototype of that for awhile. First some background…

The TI-99/4a’s video chip is the TMS9918A, released in 1979. The “4A” part of the computer’s name comes from the fact it has the appended version of the original chip, which added “bitmap mode” to the TI. After studying it and working with it for some time, I have to say it was probably one of the best chips on the market until the Commodore VIC-II came out. And even then, it was still competitive; if the TI had possessed the same level of 3rd party software development as the Commodore you’d have seen some pretty impressive games on it.

MSX Game using TMS9918A

This same chip was also used in the MSX computer systems that were in widespread use outside the US in the early and mid 1980’s. MSX games actually look a lot like classic Nintendo games; I suspect that many of the same developers went on to write NES games and used similar software techniques to maximize the hardware.

The MSX2 platform had a successor chip, developed by Yamaha based on TI’s original schematics, called the 9938 (and later 9958), which offered 80-column resolution and much greater sprite and color support. Adding a 9938 or 58 to the TI was a good way to get an 80-column mode.

So bitmap mode on the 9918A was meant to give the TI the ability to do “turtle graphics” like most of the other platforms of the day, which could freely draw all over the screen. And so it does… but with some critical differences in implementation.

Most other computers approached high-resolution video as follows:

  • Determine a color depth in bits. (Usually 1 to 2 bits, for 2 or 4 colors)
  • Create a video buffer in CPU memory of the requisite size. (A 256×192 screen would require 6K. Double that for 4 colors.)
  • Render the screen by processing left to right, up to down all the pixel data in the buffer synchronously

Six colors! Worship the Woz!

Most 8-bit computers didn’t have enough CPU cycles to render the screen with a lot of colors, so some would double the pixel width to gain more colors, creating an odd hybrid look. This was typically referred to as “artifact” colors, this effect can be seen on the Atari 8-bit home computers, Tandy Color Computer and Apple II. (Wozniak, being a brilliant engineer, also figured out a way to get six artifact colors not just four, among other optimizations.)

TI took a different approach. They extended the existing “graphics mode” which used an extended 256-character ASCII table by adding two more tables so you could fill up the entire screen with 768 patterns. Then they expanded the color table to match it in size, so you could define a foreground and background color for every row of 8 pixels. Some mathematics are required to calculate pixel location, since it wasn’t a continuous buffer, but this allowed you to have complete control of the screen to the pixel.

This approach has some advantages. Unlike every other computer, the TI can have ALL colors on the screen at all times. And with a cell-based architecture, things like scrolling are a lot easier to do, albeit at the cell level, not the pixel level.

Blue and red only intersect well in some cases…

Of course, there are trade-offs. Only having two colors for every eight pixels requires some artistic planning to prevent “jagged” effects. This is somewhat mitigated by the fact the TI doesn’t render color differential all that well in NTSC. An example: If you place two single pixels of two different colors next to each other, unless they are VERY different in brightness and tint, you won’t be able to discern them. Two pixels of the same color next to each other, though, stand out much better.

A far worse problem is that the 9918A has it’s own memory separate from the CPU. Changes to it are done through a memory mapped port, which means the CPU has to spend cycles moving data back and forth. On paper, using 16-bit memory for registers and ONLY registers for the move, you could theoretically pass data fast enough to update the 6K pattern table at a 30/second frame rate, but in practice it doesn’t work. Games such as the Red Baron Flight simulator get around this by only doing partial updates.

Also, the VDP chip only had 16K of RAM, and you’re using nearly 80% of it just to render the screen. Add in a sprite pattern table (another 2K) and you’re pretty much out of memory with no room for buffer space. This can be problematic if you want to use disk file systems; they require at least a kilobyte at the top of RAM to operate.

Finally, by separating color from pattern, it makes color and pattern changes difficult to do at the same time. Other computers had to create sprites in software by storing pixel patterns and finding ways to “blit”, or “bit block transfer” graphics over top each other to create a seamless sense of movement. The TI can do this, but not very well as you have to move stuff at least 8 pixels at a time horizontally to prevent color corruption, and two writes to two different areas of memory may lead to a “jumpy” look with color lagging behind the pattern change.

For the CRPG, I’m using bitmap mode, but a hybrid form of it. You can configure the VDP registers to mask out the extra color and pattern tables and get an “enhanced graphics mode” that gives you the color depth of bitmap mode but only in a single table. There is a small trade-off with sprites; they are dependent upon the pattern table register for some calculations and the bitmask throws them off so you only can really use 8 instead of 32, but it’s an acceptable limit.

Moran, Thomas (1837-1926) The Grand Canyon of the Yellowstone, 1872

For the title screen though, I’m using full bitmap to make a beautiful scene, based on a painting by Thomas Moran. The only problem I had was, how to draw it?

Most of the graphics programs on the TI have the same fundamental problem, they’re trying to apply a pattern that doesn’t fit the TI’s architecture. Drawing lines and circles is not the way to make a good looking title screen. Most of them fail to expose the true nature of bitmap mode as well, neither telling you about the color limitation or giving direct control of foreground and background color. (Paint N’Print is probably the most usable in this regard, but it alternates foreground/background with no indication of which you’ve changed.)

There’s a couple of modern tools you could use for this work.

Magellan is designed to let you edit character sets and draw maps, but it doesn’t have bitmap-friendly tools. (extend to three tables, plot all characters automatically to make a drawing grid, etc.)

Convert9918 is a well-designed tool to convert any existing image to 9918A format. It has a wide variety of different algorithms to color match and render images. In practice, though, I haven’t found settings to get the effect and appearance I want. In particular, details get lost and you get some weird color choices at times.

The work so far…

So how am I doing it? I wrote my own bitmap editing tool. Since I’m only really working at a pixel level, it doesn’t need to BE in bitmap mode all the time, just have a memory buffer of data I can edit on screen and then occasionally view to make sure it looks good. Using a paint program I drew a lattice of grid lines on the image I want so I can approximate things and decide which objects I want to stand out and which ones I want to mask.

So that’s what I’m doing… it’s slow-going, but very satisfying because as an artist I have control over how it looks. And I think I can make something very cool. πŸ™‚

Posted in CRPG, Design, Graphics, Screenshots, TI-99/4a | 3 Comments

Legends of Yesterday

Quick post about this, the CRPG Addict has played, won, and reviewed Legends on the TI!

His final rating is to my judgment very fair… I’m glad he found it was fun enough to finish!

I’m also really jazzed he was able to contact the author, Donn Granros, and get some interesting information about him and the game’s design.

Posted in CRPG, Review, TI-99/4a | 1 Comment

Data Dump

Been quiet for a couple weeks… I’ve been heads-down on writing up all the transactions for the first disk.

Here is a breakdown on the first disk’s contents:

  • Dialogue is in game text, stored in four sizes. (16, 32, 64, and 128 bytes with compression)
  • Monster data is statistics, graphic data is self-explanatory. πŸ™‚
  • Map data is uncompressed maps, map headers are metadata, elevation data is for specific maps
  • Mobs are special objects on the maps
  • Transactions are scripted commands and actions for a given mob

The width indicates the record’s size in bytes. Estimate is how many records exist. Sectors is how many disk sectors (which on the TI are 256 bytes) it will take up. This includes a single sector used for tracking. And finally the size in kilobytes. The total size, 176k!

One thing to note here is that the mob file WILL change as the game progresses, so it will be both read from and written to. The other files are all read-only. I always had it on the table to move the mob files to the game disk just in case I ran out of room, but it looks like I should be able to get all the content I want for a rough 25% of the game into a single 180k disk.

The script encoder has been working out well… it occurred to me a few days ago that it’s nearly good enough to be a shareware CRPG script engine! πŸ™‚

The process of scripting has been interesting. I’ve been adding, revising, and changing the actual script language as I go along. For example, I originally had commands to do various byte/word manipulations so that you could spell out all the game logic if needed. In practice, though, this leads to a lot of repetition of the same kind of activities over and over again. While I could apply an effect and give feedback if a player doesn’t have enough money to pay for healing, it’s cheaper and more economical to encompass this into a !HEAL script command that just gives the internal engine the values it needs. (Cost, power, etc.)

I also ended up revising text, a lot. I now have a text encoder that encodes the entire disk’s contents and assigns record values for all of them, outputting the contents to a text file. I can then copy and paste those values into my text spreadsheet, which allows me to easily assign them contextually in scripting. I found I was gradually shifting text more into the larger dialogue files (64 and 128 byte size) over time, but in the end this worked out pretty well for disk space. The only downside to text revisions was it meant I sometimes had to backtrack and update references…

I also wrote a new tool, a text formatter, which formatted all the text lines to fit a 30-column screen. I found that I was often much too “wordy” in places, and that I had to both cut down the amount of text and make it fit better on the screen.

Ideally, writing a complete tool that stores all the text, mobs, and transactions would be the best thing to do. Then if you changed text it would just dynamically re-assign it for you. I’m not really sure I want to take the time to write up such a complex tool though, it feels a bit too removed.

Eventually, I’ll need to write a “transaction player” running on the actual TI. This would let me pick and choose a transaction to “play” so I can view what it would look like in the game, with tools to set particular flags on or off. This will make testing MUCH easier.

I’m nearly done populating data, what I have left to do is populate the monster data with treasure items (item revisions and changes has been ongoing) and then figure out the mob system for graphics. My new design will allow for up to 256 unique patterns, so I need to define those at least for the first disk…

After that, it will be time to work on engine code!

Posted in CRPG, Design, TI-99/4a | 5 Comments