Tilting at Windmills

Exploring with the new LOS algorithm

Well, I’ve been working on various things, off and on… here’s a short list:

• Mob movement. I used a clock value to keep them from moving about too frequently. I still need to add collision with other mobs to this part, as well as a chase algorithm for monsters.
• Special terrain effects. I have four possible effects: wounding, fatiguing, poison, and slowing. They also have severity and occurrence values. Using a spell can negate all special terrain penalties.
• Option display. Most commands still need to be fleshed out, but it’s building the display at least.

The option code is also used with the combat engine, so I’m working that into the design now. I have introduced some regressions I’ll have to fix later… boarding a boat causes a status screen to pop up, which signifies a pretty nasty sedge-way in code somewhere…

This isn’t a new problem with assembly programming, really. Regression bugs are really easy to create, unless you pre-plan your code paths to an absolute degree. I haven’t done this, so there’s bound to be some oddball side-effects as I add more functionality. Fortunately, Classic99 is a good platform for quick and dirty programming, and frankly, I make a lot more progress this way.

I really want to have the total engine finished by the end of the year… the actual game contents will take more time, but will be a lot more fun and interesting.

A new way of not viewing things

I decided to overhaul the LOS (line-of-sight) algorithm in my game. I decided to use the alternate algorithm that was introduced in Ultima IV for the PC.

The results are very pleasing. It’s more permissive (more viewable squares) and it doesn’t have serious slow-downs when you’re close to or near opaque tiles. It also does less calculations overall so it doesn’t drag down the rest of the game engine. You can see in the screenshot that it has some interesting effects, allowing you to see around blocks of opaque areas in some cases.

How does it work? Well, instead of tracing paths from each tile to the center, it traces from the center outward. It first does the cardinals, which are easy, checking for opaque tiles on the way out. Diagonals are a little trickier; here it has to check three squares around the target one, and if any are open it opens that one as well. I suspect I could have a “minimum number of open tiles required” here if I want to make it more demanding, but I think the current effect is fine.

The original algorithm in C is pretty simple, a set of four loops with a bunch of IF conditions. Replicating this in assembly was not so simple, but I managed it… mainly it’s trying to do it in a compact way that recycles code. I also used a data array to indicate direction and vectors.

Now that that’s done, I can move on to the command/control system, which will also be needed for combat, inventory management, and so forth.

Work continues on pacing… In particular, with the update of the display.

I’m already using a secondary screen buffer, which lets me build the screen out of sight of the player and just do a single video register write to change the display. That’s just good sense, really… It does mean you need to rebuild the display every time, though.

The problem I’m running into now is that I’ve added state tracking, so things slowed up a little. In particular, I’m noticing the amount of CPU time that the LOS (Line-of-Sight) algorithm is consuming. Most of the time it’s all right, but getting close to blocking objects causes things to slow down quite a bit… and speed up considerably when LOS is off.

There’s a spell effect in the game (called “magic eye”) which turns off LOS. It’s a limited effect, but while it’s on, I don’t want you to “zip” around the screen. One, it makes control a little difficult. Two, it clearly illustrates what LOS is costing you in CPU time.

I found out a few things when I turned it off… My “wait for the current sound to finish” delay wasn’t nearly enough with LOS off to delay it to match when LOS was on. For awhile I thought my delay for sound wasn’t working at all, but it was. In fact, I don’t need that code anymore at all.

My new code stores the current clock value (which is incremented every time interupts are called, every 1/60 of a second) every time you move. Then when it goes back to the main loop, it checks to see if a certain number of ticks has passed. If not, it holds off until that number is met. Right now, 16 ticks (About 1/4 of a second) is about right.

Still, it’s revealed one of the worst cases on the LOS is when you have blocking tiles really close… like immediately around you. Technically the algorithm should be able to wipe the whole board cleanly when this happens, but it doesn’t, it still calculates every single square. I need to consider if a special case exception would help here…

Did some new stuff last night…

I wanted to test state tracking out, so I put in the code, which I’d previously written for the combat engine, that tracks party and player states and updates as needed. I then edited my save file to add some conditions like poison.

I think I’ll need to move my icon display for states to below the Health/Stamina bars… as is, the displacement of the health and stamina bars is too eye-catching to miss. The other issue was timing; the screen updates weren’t in good sync with the sound; it appeared like you were lagging behind. I updated my sound effects to occur after the screen buffer swap so that it should all appear to happen at the same time. I just hope the display updates don’t cause too much of a drag in general.

In order to test the sound issues, I had to port back to MESS for a bit, since Classic99 has no sound. (Boo….) Fortunately, TI99Dir let me copy the Classic99 files back into a disk image. I was even able to port it to my TI, as TI99Dir supports my CF7A card reader system. Did I mention how awesome these utilities are?

Then again, MESS’s TI controller emulation may be a little too good… loading up the game was monstrously slow. It did reveal a small bug I’d introduced, loading the item set graphics while the screen was still visible, something I didn’t see in Classic99 because the access was so fast. And the Myarc controller failed to load the game… I’m not sure if that’s because TI99Dir’s copying created an issue or if the Myarc controller still has problems in MESS.

I may introduce mob movement into the engine as well… state tracking includes this, and I’d like to have the whole “turn based” system figured out before I move into combat in earnest.

I’ve finally finished my regression work. Replacing some hard-coded addresses with labels, changing some data, and I finally have the full functionality of the engine restored.

Classic99 in action

Classic99 has proven itself as an excellent emulator for development. It runs quickly and fast, and I particularly like I can view the screen in NTSC mode… this means I have a better idea how it really appears on my actual TI. Actually, my real TI screen is a bit worse… those old NTSC cables and signals were definitely dodgy in places.

The compiling speed is good too, enough on maximum speed that I’m considering just building the combat engine into the current one, rather than separately. This would prevent a lot of integration errors later, and give me a better idea of how big the program’s getting.

The only thing Classic99 doesn’t do right now is sound… oddly enough, it was working just fine, if a bit loudly, in the prior verisons, but recent changes seem to have broken it. The interrupt-driven sound method used by the TI developers has some oddities to it that perhaps aren’t being quite captured. Tursi is planning a total rewrite of the sound core in the future, so I’m not too concerned.

As part of combat engine development, I also need to improve the overall control system. Most CRPG’s are really just data management in disguise; at present my engine just has some hard-coded directions. I need to replace it with a system that determines available actions based on the active character, which it will also do in combat.

I’m sorely tempted to start on inventory management as well, since both spells and inventory will be controlled by the same interfaces in both travel and combat… but anything involving player input tends to burn up memory fast, which can be alarming to see, and I feel like I’ve put off combat for far too long… more than a year, in fact.

A few more fixes tonight…

The sound problem was pretty simple. I’d actually freed up another 256 bytes for sound data, and I had moved the table to compensate. MOST of my data table had taken this into account, except the trailing branch to the silence sound… and the sound generator, which interprets byte-by-byte, really doesn’t handle data that’s not properly formatted very well at all.

The player graphics was simple too; I had updated placement of variables in various arrays and not adjusted my code to match. Frankly, my lesson here is, if you change ANYTHING, hunt down every single use of that particular variable/array first in code and make sure all changes are corrected for. Unlike a high-level language, assembly tends to rely heavily on constant and immediate values in code, because they’re faster and easier to use. They’re also harder to maintain.

I may have to rework my test data as well. Attempting to enter town caused a re-load of the main map. This is likely because I also changed mob types to different numbers, so my old data is out of date, or not quite synced up right. I definitely want to only fix what’s there and not go too far, because it’s pretty easy to keep working on refining the travel module of the engine and leave the combat engine untouched…

Well, got many of the disk file issues in Classic99 sorted out… Tursi, the developer, was quick to respond and quicker to effect repairs on his disk system, so it appears that for the moment, the emulator is in good working order to develop in. Well, except for sound, which is curiously broken in places.

So the first time I compiled my new source, the game had a nice video garble screen and no responsiveness to the quit key… which means the CPU is doing something that prevents interrupts from getting in, and writing to video memory is involved. This typically occurs when you have a video write operation with an obnoxiously high value it’s counting down from.

I found that problem and fixed it, only to find it continued to freeze up, and attempted to load files from the wrong places… this was because I moved the location of the file data slightly but failed to update an immediate address in the code to compensate. Oops. :S

Then I had MORE video garbage when it loaded up the screen. This I traced to something really interesting; I had some hard-coded data values to indicate the size of the “stat” screen window, which was an odd-byte count, but my “clear out” function was counting in words, 2-byte increments. This meant it actually went straight from 1 to -1, skipping zero entirely and started over-writing the entire CPU memory. Simply changing the data value to an even number fixed the problem.

And I’m not done yet, of course. I’m paying now for the numerous design changes I made to the basic game structure, and that I didn’t make each single change one at a time, compile and test, until it was solid. Oh well. For the most part, my logic was sound, it’s just in minor details that things slip up… the problem being in assembly language, a minor detail can lead to rather catastrophic crashes.

At this point, my plan is to finish up the current engine model’s regressive changes at the least, and label it as demo 0.45. I may also add some new functionality; there’s basically a patchwork control system in place in the current form, and I really need to have it based on the active character and determine potential actions. The same thing has to be done in combat, so I should reuse the code if I can.

A few long hoped-for wishes of mine came true recently…

The first is that I finally contacted Quinton Tormanen, a TI developer from the late 80′s/early 90′s. He had written some truly amazing game software released through Comprodine Software and then disappeared. I had met him at a TI faire in Portland, Oregon in 1990, and possibly being bemused by my ardent fanboyism, showed me the prototype/alpha of his current project, a Gauntlet clone for the TI called “Gold Vault”.

Anyway, Quinton is still around, and he still has all his old TI stuff, but he hasn’t used it in years. He told me he never finished Gold Vault because he was never happy with the action, and he had also been working on a Might & Magic clone. Both projects were so large, though, he eventually lost interest, around the same time he made the permament move to PC development.

The other big thing to happen is that Tursi, possibly as a belated birthday gift, re-wrote his disk system in Classic99 so that it can at last support assembly work! And to make things even better, his emulator can directly read PC text files and treat them as TI text files, so I don’t have to even convert my source over. This will greatly speed up my development time and reduce my frustrations… well, maybe.

There’s still some kinks and bugs to work out. My initial rewritten code promptly crashed on me, which lead me to unpack an older demo to see that the assembler and Classic99 were still working with it. It does, but my older demo has shown some oddities… sound is nearly absent; only a few sound effects work. It also has problems accessing two relative internal fixed files, although others work fine.

File troubles are nothing new, really… for example, relative record access isn’t documented very well in any of the available TMS9900 materials. I originally had my starting record set in the open part of the DSR, only to find that the Myarc Controller habitually assumed 0 for the starting record regardless of what was in the peripheral access block. So I wrote my DSR routines to just populate the record after the open, which worked for both controllers. Since some of my files work and others don’t, and this worked fine in MESS and on my actual TI, I figure it’s either a bug in my code or Tursi’s. Probably mine, or none of the files would work.