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

Moving On Up

If the site looks a little different to you, there’s a reason… I’ve relocated the blog!

My WordPress blog on Yahoo has been stuck on a prior version for several months now. When I contacted their customer support, they pretty much said they weren’t compatible with the latest and that they would have it working “eventually”. During which time none of my posts propagated to the main site unless I explicitly attempted (and failed) an update. I also ceased getting emails telling me that a comment was awaiting my approval.

I’ve been unhappy with Yahoo as a host for quite awhile now… Aside from the fact the company always seems to be on the verge of Chapter 11 these days, they split off their business web hosting side into a new company called Aabaco, part of some larger futile effort to avoid taxes or leverage more money out of it. The result is poor lackluster service.

We’ve been using AWS (Amazon Web Services) at work for the last few years, and I’m impressed with their work. In particular, storage space is very affordable, and running a WordPress blog should be pretty cheap! (After the first free year of course.) So I’ve relocated there and been very happy to do so!

Fair warning, I eventually want to put up some pages for my CRPG, so I may stop re-directing the main domain to my blog eventually. You’ll always be able to find it at adamantyr.com/blog!

Posted in Blog, CRPG, Personal | 4 Comments

More Ingredients

First of all, congratulations to Sinphaltimus for being the first player to win Wizard’s Doom! Along the way to a 93 rating, he also discovered several bugs I had to fix with the final encounter… Well done!

As I’m working on the CRPG, I want to make sure that the game has enough depth in play that it remains interesting all the way to the end. Some things I’m adding and changing in design:

  • Weapons, armor and spells now use a damage type system, with slashing, piercing, blunt, fire, cold, etc. This allows for nuances like a skeleton being tougher to kill with a sword than a club.
  • Weapons now have a throwing quality, so you can throw them in combat. Most are one-time use in this manner and it leaves you without a melee weapon for the rest of the combat. Some magical weapons return to you, allowing unlimited use in this manner.
  • As part of moving item names and attributes into CPU memory, I can also have a “readied” weapon approach much like Tunnels of Doom did. So switching from a melee to a ranged weapon to a spellbook takes an action point.
  • I may expand the party size from 4 to 6, but only allow you to create up to 4 maximum to start with.
    • On that note, I may need to add a “hostel” system of some kind so you can remove characters but retrieve them later.
  • I’m considering adding an “item storage” system so you can bank extra items for retrieval later.
  • After thinking about it awhile, I think I will add in attributes and also expand out the skill sets. Because I can keep more active data in memory more easily, the calculations aren’t as crunched as they used to be. My chief concern is to avoid having any classes become automatically “better” than another.

I’ve actually completed all the regular sized monster graphics for the first quarter of the game, which was a lot of fun to do. My “monster editor” proved to be an easy and fast tool to do the work with!

The “boss monsters” are taking more time, mainly because I’m trying to get them to look just right.

I’ve also been re-working monster statistics to match my new approaches. For certain damage types, reduction applies, for others it doesn’t. That means monsters may end up with a lot more health than the players typically have, since they may have no damage reduction at all against a particular common attack.

I still need to get the transactions done for content, and I may need to create some more tools to convert text listings into binary code so I can easily update item lists, monster statistics and so forth. After that’s all done I hope I can start working on the common and travel modules and getting the game engine back on it’s feet!

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

Putting it Together

Hello everyone… Or like, both of you. Or one of you. Maybe. 🙂

I’ve actually been hard at work on the CRPG for several months now… After the TI faire I got myself an AMS card, which gives the TI a megabyte of CPU memory to play with. I decided that I wanted to upgrade the CRPG to use it, so that I could do a bunch of things I wasn’t able to do before.

The biggest pain point with this is the architecture change. Most TI software wasn’t designed with segment/module coding in mind, and as a result, there’s almost no way to write them. A gentleman named Art Green did write an AMS linker way back in 1993, but it’s a bit heavier than I’d like, and it would require me to do all my compiling in emulation rather than with an external tool.

So in order to make it work right, I will have to write three different sets of source code, one for each major module in the game coupled with a common module. Then I can compile each module to fit in the original 32K confines, take the compiled code and create the necessary binaries that will be loaded into paged memory. I’ll also have to write my own custom loader as well…

This approach will let me do some things I really wanted to do but due to memory constraints couldn’t. For example:

  • Double-sized monsters, occupying 4×4 characters. Perfect for large creatures like giants and dragons
  • Multiple monsters, such as a group of bandits accompanied by a bandit captain and a rogue sorcerer
  • NPC’s who can join a party that is under 4 characters in size along your travels
  • Graphics sets, items, spells and sound effects are all stored in CPU memory for much quicker load times! (I’ve been spoiled in emulation with extremely fast speeds)

Right now, I’m working on content. I realized I needed to have some actual game content to complete, test, and refine the game engine. So I have divided the game into rough quarters, and am working on the first disk, or 25% of the game.

What have I got done?

Well, the first thing I did was rework the graphics. Now that my TI is setup and running, I was able to re-evaluate them on an actual NTSC screen. I also decided to change my approach and use more colors to make them “pop” better… something MSX games did to very good effect. I’ve been very pleased with the results! This is definitely a TI game that makes FULL use of bitmap graphics capacity.

I then completed all the maps for the first disk. This was time-consuming, as some hadn’t really been even drawn on graph paper, and only existed in concept. I also didn’t want to waste a lot of map space on a map that had only one purpose, so I was removing and adding entries all the while. I also made elevation use an option, so not ALL maps have elevation. This saves some disk space and is more efficient, since most maps don’t need it.

A big change was I’ve dropped the idea of storing battle maps on disk. As I increased the terrain types, I realized the battle map file was consuming a ridiculous amount of memory. I was aiming to keep each quarter of the game to fit on a single 180K disk, and the battle maps easily pushed it over. So my plan now is to create battle maps dynamically based on the terrain around the player. I’m still thinking about that algorithm, but with the added memory it should be doable…

I also completed all the mobs (mobile objects) for the maps, although many have empty data values for monster tiles and dialogue/transactions. My goal here was to determine how many mobs I would need, and it worked out about where I thought it would, just over a thousand for 64k of maps. As part of this, I wrote a new tool in C# to create the mob binary coding from text files. This lets me make changes quickly and easily, then just paste the entire block into a binary file.

I’ve written out all the dialogue for the first disk, although I’m constantly adding and removing entries… My compression algorithm wasn’t quite as effective as I’d hoped; it averages about 18%. But for now it works pretty well. I’d have to write some tools to find common words in my actual text blocks if I wanted to try and write a better one. A job for another day…

I’ve also decided to make monsters game disk-specific as well… It just makes sense, monsters are geographically located and if you end up repeating a few it’s not a big deal. My initial write-up ended with around 84 monsters, but that could go up or down. This is ongoing work because I decided to give monsters a full bitmap color block, which means I have to redesign the graphics to take advantage. I realized that there weren’t really any good tools to do monsters easily, so I wrote my own! Hopefully I can have some fun with it while I draw them up…

The next stage will be writing up all the transactions. I have a few done, but it will take awhile to write ALL of them… and there will be considerable cross-referencing done with the mobs and dialogue on the way, which makes it very time-consuming. I figured I’d end up with at least 2k (2048) transactions before I’m done, but it could be easily double that. Fortunately they take up very little space on disk.

Once I have all the game data done, it’s on to the engine! My plan is to get the Travel module done first, followed by Management (Inventory & transactions) and finally Combat.

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

Running the Gauntlet

Hi all!

So I went to Fest West 2017 this year, down in Woodland, WA. It was a 3+ hour drive for me to get there, but well worth it. I met a lot of great guys and saw some pretty awesome stuff. I was even able to acquire a new NanoPEB that DID work with Wizard’s Doom (Apparently my CF card reader is, in fact, busted in some weird way) and an Extended Basic 2.7 Suite cartridge. Going to a convention for your vintage computer hobby is a lot of fun and it really helps inspire you to do more with it.

So what’s my next TI project? Well, I’m taking a short break (hopefully) from the CRPG to do something a bit different, an arcade/action game. I’m also returning to assembly language, because I want to really push some limits on the TI.

Specifically, I want to write Gauntlet for the TI. 🙂

Why? Well, it was far and away one of my favorite arcade games back in the day. Even as a kid I was fuming that it was available on the Commodore 64, Atari 8-bit, and Apple systems but not the TI. And then recently I discovered the ZX Spectrum and the MSX platform had it too! 🙁 Knowing a MSX version existed though made me realize it SHOULD be possible.

The first thing I realized was I could not use the baseline TI’s memory. Every single port of Gauntlet for the home computer system market had at least 64K of RAM, and it’s needed! In particular, storing graphics and animation frames consumes a LOT of space. So I am using the SAMS card to make sure there’s plenty of RAM available. This solves some other problems as well; I can use memory-over-time solutions in several places.

The biggest hurdle is going to be updating graphics in real-time. The MSX version (which I studied in a debugger) essentially keeps the character sets static in the upper 2/3 of the screen, only changing them dynamically in the lower 1/3 for the 3 rows of graphics. They also only change patterns and not colors for animation. I want the TI version to do better than this. 🙂

I’m not going to call the game Gauntlet for a myriad of reasons, mainly because there are aspects of the game I don’t like that I want to make changes to/improvements on, and I also want to port some of the fun things from Gauntlet II into it.

Currently I’m working on a prototype scrolling map display to see how it performs. The basic algorithm is as follows:

  • Store the entire dungeon map as a literal set of tiles, each tile is 8×8 pixels in size. There are a potential of 608 unique patterns, so a full word (16-bit is needed.)
    • This will consume 8192 bytes, or 8k.
    • The map has NO mobs (movable objects such as monsters)
  • Extract the viewable area from the map into a buffer space, which is slightly bigger than the screen. Wrapping occurs if it goes beyond boundaries.
    • This is refreshed anytime the map is scrolled or mob movement is done
  • Iterate through a mob array, checking if a mob is present in the viewable area. If so, copy their tile patterns to the buffer in the appropriate location.
    • Also store the mob you just placed into a “visible mob array” which stores their local coordinates. That way you can quickly decide actions for mobs that can actually move.
  • Using a “character pattern index” for the section of the bitmap video display, create a “view buffer” that uses actual character pattern values (0-255).
    • If a given tile isn’t in VDP yet, get it there, either immediately or store it into a larger buffer that’s written all in one write.
    • If you run out of patterns, reset to zero and restart.
  • Write the character pattern changes to VDP.
    • I may utilize a hybrid bitmap mode so that the upper 2/3 of the screen use the same character pattern set for better speed.
  • Write the view buffer out to the screen. This may also include updates to the bottom statistic area such as health count and score.
  • On given interrupt intervals, change the animation patterns used and update accordingly.
    • This is where it could get messy; I may need to have a separate stack array that stores the current “mob” patterns that need updating in a given block.
    • For simplicity it may be best to just do a complete linear write of patterns and colors rather than trying to do them individually.
  • Animated static tiles (like treasure chests) are only animated in color, not pattern

The big question is, will it be performant enough for an arcade game?

I don’t need the view to scroll particularly fast; if you play the arcade version of Gauntlet, which I have in emulation quite a bit, the map actually scrolls at a steady speed. Even if you are playing an Elf who moves very fast, the map speed doesn’t change. But I don’t want to see distortion or glitches while it updates either.

The question is if the animation will slow it down too much. I had a thought of having the animation patterns just be brand new characters introduced and replaced, but this will DEFINITELY overload the pattern buffers, forcing me to either clean up unused ones or redo the entire buffer from scratch more periodically.

But you don’t know until you try it all…

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