Tilting at Windmills

Slow work on the CRPG the last week or so. Got some big real life stuff going on… just put an offer down on a very nice townhouse that was accepted. You don’t own it until you close, of course, but it’s looking good so far…

What I have been doing is some re-architecture of files. In particular, I decided to have two sound files, one for travel mode and one for combat. This gives me the whole buffer (2k) I have set up to devote to combat sounds without sharing space. This means splitting the data and also identifying “overlap” sounds that are needed in both modes. I could actually store sound data in records instead of memory-images, but sound data is particularly variable-length in nature, which means I’d end up with a lot of wasted space.

Consider that a “record” would likely be 128 bytes. (Yes, some sounds can easily consume that much.) That means storing 32 sounds would take up 4k on the disk. And some sounds wouldn’t use up the whole record, which is a lot of waste. So far I’ve been able to make 2k stretch pretty well, and it’s always accessible without any disk access.

Another change was to stop storing my “mob” character graphics, the 8×8 patterns for moving units on the travel screen, in CPU memory. There were 32 patterns, for a total of 256 bytes of high memory being used. I have room in the VDP for that, so I’m moving them out there. That means modifying another memory-image file’s base address and size to include the mob graphic data. Should be easy, and the added access time for two VDP accesses (read in from VDP, write back to VDP) should be minimal compared to what it would cost pushing them out to disk. I’ve considered pushing tile data into records, which would let me have as many character sets as I have file space and file count for, but for now I’m just keeping them in a static VDP location for speed.

I also decided to mine a few more classic TI cartridges for sound effects: Parsec, A-Maze-ing, and Alpiner. Sound data is always in the GROM for these old cartridges, but finding the data can be a bit of a hunt. You could use an emulator with a debugger (such as classic99) and check the value of the sound ISR routine’s address to find them, but you’ll still need a hex editor to extract the data out. ISR sound data follows a particular pattern: Searching for >E3 or >E7 values is always good because this is the setting to make the noise generator use the third voice’s frequency as its value. Not all games use these, though, so you also want to look for sound setting patterns and low-byte values for the count of bytes (Which is 1-12) followed by a duration byte (which is usually low). So far, most TI cartridges have been well designed and have kept all their sounds in one place, rather than scattering them about.

A few interesting things I’ve discovered:

• Parsec’s laser blast noise is nothing more than a single voice, brought from a very high to very low tone rapidly (Only 1/60 duration per change). The volume is a bell curve, louder in the middle and soft at the ends.
• The third victory tune in Alpiner is the opening of “Promenade” from Mussorgsky’s “Pictures at an Exhibition” suite
• Most of the sounds effects in Alpiner only use a single voice, probably so they don’t override the background music

After I finish the file changes, and make certain everything still works all right, it’s on with combat! I’ll admit that I’m a bit distracted into some sound crafting; it’s creative work and rather fun. I would rather have a “needs work” sound in place for combat than just a “beep” or nothing at all.

I completed the integration of the new attack code into the engine, along with all the necessary regression changes. The engine now occupies 16k of high memory with the lower 8k in CPU RAM as data space. Hopefully the program doesn’t get so large that the SAVE utility no longer works…

Latest Statistic Screen

Things left to do include:

• Combat attack, fire, spell casting, item using
• Enemy AI
• Combat FX and result feedback
• Battlemap loading and unit placement
• Ambushes
• Monster statistic screen
• Inventory management
• NPC interaction
• Quest interaction/tracking
• Mob interactions (doors, traps, etc.) and alteration

Still a lot of work ahead, but I feel a bit more confident that I’ll be able to squeeze it all into a standard TI-99/4a with a 32k expansion. I may need to go back and compress some code or re-architecture it like I did with the attack routine, or push more data off to the VDP or disk. I also uploaded it to the CF card and tried it out on the actual hardware, looks good! Although I definitely noted that the CF card is slower in disk access than Classic99. I need to be careful about that; it’s easy to forget in emulation that things aren’t as fast.

Latest Equipment Screen

Along with a new color monitor (A Magnavox Color 80, which any retro-computer type would know was one of the best of the era), I picked up the references manuals for the Commodore VIC-20 and 64 at RE-PC last week. (I was going for TI stuff, but Larry Correa from the Yahoo 99′ers group cleaned them out of everything.) I wanted to take a look at how graphics were done with the eventual idea of making a 6502 port of the game. Plus, I’ve always wanted to know more about how these systems worked.

To my surprise, the C64 in particular is rather limited in comparison to the TI. Instead of having the colors tied to the ASCII set like the TI, the C64 has a color map for the screen. This has an advantage; it’s easy to do different colored text and numbers on the screen, for example. However, it also means that for something like a scrolling window of characters, you would need to update both the screen table AND the color table to keep them in sync. Since both are located in different memory areas, two accesses are needed. Then again, the C64 also has the advantage of  memory-mapped video, so it does this much more efficiently than the TI could.

However, the TI is also capable of much better color definition. Using enhanced graphics mode (admittedly only available in assembly), the TI can display 2 different colors per line in an 8×8 block. The Commodore is  1 color and one universal background color per 8×8 block. There is a higher graphics color mode that has 3 colors and one background, but it requires raster interrupts and also reduces the screen width in half (so each pixel is 1×2 in size). I’ve heard that some c64 programmers found some cunning methods to get both the higher color count AND resolution at the same time. But I’d have to ask, myself, how practical it was to implement and if it was workable for a game, instead of a demo.

Latest Spellbook Screen

One thing both systems have in common is the use of an ASCII character set which can be redefined for graphics. This is very nice. I’m not sure how much headache an Apple II version would be yet… Apple II graphics with their 6-colors are an engineering marvel but rather confusing to those of us who didn’t grow up programming with it. I’d like to do an MSX and ZX Spectrum version as well… the latter has a chip very similar to the TMS9918A, but limited to 8×8 blocks much like the C64.

Aside from different computer versions, would be rather cool to do different language versions as well… German seems likely, I know a few 99′ers who are German. Not sure about any East Asian languages; the old character sets just aren’t large enough for the task. But, er, I’m getting WAY ahead of myself now.

Been working slowly at the extensive regression changes to accommodate my faster attack routine. After completing it, I was pleased to see it only occupy 602 bytes, including the data arrays. I’ve reworked the stat screen generation as well, so it should display the new data, such as attack fatigue. By this weekend I should have it back up and running, and I can continue my combat engine efforts. You can take a look at the two different attack routines on a post I made at AtariAge.

While I was doing this, I also created an entry for the Short but Sweet Contest on the TI-99/4a boards at AtariAge. The contest rules were quite simple:

• 30 lines maximum of code, 10 lines of data additional
• Extended BASIC or BASIC (Although you really don’t want to use BASIC)

Unlike the prior contest, which only in the end had two completed entries, there are now over a dozen completed entries on the board. And they’re all VERY impressive work.

It was interesting programming in Extended BASIC again. Much to my surprise, I remembered the programming style and tricks very quickly, and I was able to put together my game “Dark Maze” in about four hours of work. Refinement and changes took longer, of course, and the game runs VERY slow at native speed, because the GCHAR calls to uncover the map are a huge speed trap. Fortunately, in the emulator of choice, Classic99, you can select “CPU Overdrive” which speeds up the computer considerably while keeping it usable by a player. My game isn’t the only one that requires this.

It’s a good board at AtariAge, with a lot of 99′ers coming out of the wood work and just having fun programming on a computer they love.

Short and Sweet (SSGC) Contest at AtariAge

Dark Maze at AtariAge

So, I wrote up my attack routines for melee, ranged, and sorcery attacks. The source file size was considerable; the only larger one in my directory was the one for display functions. In the end, it clocked in at 1168 bytes of code.

Yeow. That’s gotta come down. It’s a large chunk of logic, to be sure, but I should be able to cut that in half.

The main source of bloat is the fact I have three separate routines for each attack type, each of which has a lot of the same pattern of code. Check for this state, check for that state, do miss check, do critical check… this could and should all be in one monolithic function that just has data stored to indicate which state, which values, etc. to use for calculations.

I got a suggestion to just alter the attack/defense bonuses and other factors when states are active directly, so that no “updates” are needed in combat. A nice idea, but then I just end up moving this logic from the combat routines into the “state check” routine that occurs round by round. All they do right now is decrement counters, and they’re only for the players, not any monsters, since it also operates in travel mode. Finally, this data is stored in a VDP data array, which means accessing it is slow; not something to do bit by bit.

Also, every attack is unique. If a defender has a spell that increases the attacker’s chance to miss, for example, this affects the attacker, not the defender. That means  you can’t pre-process values in, because they are dependent upon who is attacking whom, and what states they have active.

So, I decided to do several things:

• Expand the player array to include fatigue costs for all actions (move, melee, ranged, sorcery) and critical ranges. This reduces the amount of dynamic checking needed
• Alter some of the more problematic spell effects to be easier to manage. For example, one spell granted a bonus to melee attack and speed and a penalty to melee defense. Instead, I’m going to have it increase critical range and melee fatigue cost. This keeps the spirit of the spell I had in mind, and makes it less problematic to track as it only affects attack
• Express the different states and their effects in data format instead of in code. That way my attack routine becomes a data-driven engine instead of a bunch of linear IF/THEN type statements
• One minor change is to make the light counter and tracker a party-based one instead of individual character-based. My original envision was that the party had to have a “torchbearer” who had to sacrifice an offhand slot to carry a light source. This is way too much trouble, though, so I’ll just have light sources get “used” and it grants N rounds of R radius light to the party

These changes will increase the size of the player array which is no big deal. The save file is presently 512 bytes, and a good portion of it was unused, for future use in party quest tracking. I’ll have to make a ton of regression changes, though, to accommodate moving around values in the array. And redo my statistic screens again…

I’ve got the changes to the stat screens done. I moved equipment off to the second page so I had more room for stats on the main page. I thought about just not displaying some values, but I’m already concerned about the lack of feedback being too frustrating, so I’ll err on the side of caution for now.

Now I’m back to regression programming and testing for a bit.. then I’ll tackle Attack Routine 2 : Faster, Better, and hopefully Smaller…

I found the problem with movement… quite simple, really. I had byte vectors that weren’t quite accurate. A -1 applied as a word requires the whole word to be formatted as -1, not just the right byte. Otherwise you end up with units moving diagonally. A few quick fixes and my units aren’t moving over top of each other or in odd directions anymore. The code base is ready now for the actual “attack and defense” routines, which should be interesting, since there’s so many factors to account for. I also need to find a way to cleanly map area attacks to units affected… preferably with a single routine that can “map” the damage area.

For your entertainment, I recorded a video in Classic99 to show off the start of the combat engine. In particular, you can see the units don’t move in quite the expected order.

Hopefully this gets SOME comments…