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…