Tilting at Windmills

And back to CRPG stuff…

I was at a remote forested area which had a beautiful viewpoint from a forested hill of a waterfall across from it. I realized such an awesome view would be impossible to do in my current engine because the forests would automatically block your sight. That got me thinking about the concept of elevation in my CRPG.

If every tile on a given map had an elevation value, you could automatically consider anything lower than the current location’s elevation as view-able, and anything higher as not view-able. That way you could create canyons and depressions that limit visibility while hills or lookout points improve it! I’d only need to use about 3-bits (0-7) to get a good amount of range too. Tiles like forests would continue to block line of sight at the same elevation, unless you were above it.

As I pondered the implementations of it, I realized I had one small problem; I’d need more memory to support an elevation map in the game. Right now I have a 4k buffer for maps; I would need to either shrink it to support an elevation map, or find more memory somewhere. (I’m thinking I could use about 3k for tiles and 1.5k for elevation/light mapping… I’m sure I can dig up 512 bytes somewhere.)

Why don’t I compress the maps with something like RLE (Run Length Encoding)? Well, that’s mainly to save disk space. You still have to decompress into your local memory. And disk space isn’t an issue with this game; a primary difference from developing vintage games in the modern era is that you don’t have the concerns of manufacturing and packaging floppy disks. So you can use the biggest disks available without fear.

For now, I’m marking this idea as a P2 (Priority Two, nice to have but not strictly necessary) and shelving it. I really want to finish the combat system before I return to travel mode. And I should get the quest system and other elements done before I go around adding new things to other modes.

Combat engine work is still mostly idle; I’ve been trying to complete my spreadsheet of FX data before I go any further. This is so every spell has a combat effect that I can test and make adjustments to, as needed.

The way I handle FX in the game is essentially an engine that processes commands in 8-byte segments. There are commands to create sprites of a given pattern/color and animation style, move sprites from one point to another, create a circle, cone, or line effect, and so forth. But I have to have data to test.

One big element that will require a lot of testing is the timing. For several of my effects, I provide for a delay count so that the engine knows when to stop and move on to the next effect (if any). Sound effects are handled by the interrupts, which means they can’t really be used to time things. So I’ll need to try effects, make a judgement call on how well they look, and make adjustments as needed.

On the subject of sound effects, I’ve been doing a little redesign there too. I went back to the Tunnels of Doom sound effects to borrow a few (the monster ones are particularly good for negative effects) and I’m always impressed by them. The sounds are VERY small, only taking around 19-21 bytes of space each. Each seems to follow a pattern of three different tones, but also use the noise generator and different duration to achieve an effect. I’d like to go back and redo some of my positive sound effects (healing, curing, etc.) to match the same pattern, but that will take awhile and I have stock sounds I can use in the meantime.

Right now, my list of tasks is as follows:

1. Fill in FX for all combat-oriented spells. Use placeholders if need be for some.
2. Expand the action array to include direction of attack and other elements. I originally was trying to squeeze all action data into a single word (16 bytes), but now that I’m not processing sets of actions anymore, I can make this more informative and easier to use
3. Fully split damage out from attack. My initial code had them closely tied together; this won’t work for area attacks, which ignore defense rolls. It also needs to consider effects, like positive/negative states.
4. Make sure that area attacks that affect multiple units will process against all affected units and locations. I’m pretty sure this is set up, but it hasn’t been tested, and I may have biased it towards one unit while doing ranged attacks.
5. Look into whether or not I can condense and data-orient the effects routine. Right now it’s 426 bytes of code that just changes a state array directly with addresses and instructions. Writing a data array structure that can do everything could be tricky though.

Plus I have two bugs to fix:

• When the wizard uses a wand, the wand effect pattern doesn’t appear to be changing orientation, as opposed to the arrows/quarrels used by the other party members. Could be a data issue?
• Some shots at particular angles are traveling well past screen boundaries and looping around. Smells like an overflow math issue with calculating the slope.

I’m still working on content changes right now… graphics, sound effects, actual FX for all the spells… a lot of work to do before I go back to coding up things.

One aside was to update my animation code. I’ve had the same block of code in place for several years, and it’s functioned adequately. But it’s hard to expand, as it’s really just a set of linear instructions for each character block. Some sample code is this:

* Tile animation
ANIME  DATA AWS,AM1
AM1    MOV  @CLOCK,R0
       ANDI R0,>0003
       JEQ  AM15
       RTWP
AM15   LI   R0,>2468
       LI   R1,HIBUFF
       LI   R2,40
       BLWP @VMBR
       LI   R1,32
       BL   @ANORTH
       C    @CHAR,@W1
       JLE  AM16
       CLR  R1
       BL   @ANORTH
       LI   R1,8
       BL   @ANORTH
       LI   R1,16
       BL   @ANORTH
       LI   R1,24
       BL   @ANORTH
AM16   LI   R0,>2468
       LI   R1,HIBUFF
       LI   R2,40
       BLWP @VMBW
       LI   R0,>0400
       LI   R1,HIBUFF
       LI   R2,104
       BLWP @VMBR
       LI   R1,64
       BL   @ASOUTH
       LI   R1,72
       BL   @AWEST
       LI   R1,80
       BL   @ANORTH
       LI   R1,88
       BL   @AEAST
       MOV  @CLOCK,R1
       CLR  R0
       DIV  @W16,R0
       MOV  R1,R1
       JEQ  AM2
AMEND  B    @AM7
AM2    MOV  R0,R7
       ANDI R7,>0003
       LI   R1,24
       BL   @AROT
       LI   R1,32
       BL   @ASOUTH
       LI   R1,40
       BL   @AWEST
       LI   R1,48
       BL   @ANORTH
       LI   R1,56
       BL   @AEAST
       CI   R7,3
       JNE  AM25
       CLR  R1
       BL   @ASOUTH
       BL   @AEAST
       LI   R1,8
       BL   @ASOUTH
       BL   @AEAST
       JMP  AM3

This kind of imperative linear approach is all right, if you don’t have a lot of things to do. Truthfully, in assembly language, you often have to balance whether or not a more generic data-driven approach wouldn’t just end up costing you more memory than its worth.

In my case, my animation requirements DID get up complicated enough I wanted to get away from this approach. I also wanted it to be easy to add new patterns or alter exiting ones (and their animation speed) with a simple change.

Here’s some of the new code, which uses a data array to store the VDP address, size, and speed and type of animation. It’s then processed in a short loop:

* Tile animation
ANIME  DATA AWS,AM1
AM1    MOV  @>8314,R10                 * Copy stack address to R10
       MOV  @CLOCK,R0
       ANDI R0,>0003                   * Check clock value for 1/15 interval
       JEQ  AM2                        * If not, skip animation
       RTWP
AM2    LI   R8,ANDAT0
       BL   @ANIMAT
       C    @GSTATE,@W2                * In combat mode?
       JNE  AM4
       LI   R8,ANDAT2
       BL   @ANIMAT
AM3    RTWP
AM4    C    @CHAR,@W2                  * Is character set 3-7?
       JLE  AM3
       LI   R8,ANDAT1
       BL   @ANIMAT
       JMP  AM3       

ANIMAT MOV  R11,*R10+                  * Animation looping for blocks
       MOV  R8,R9
       MOV  *R9+,R0                    * Load character data 
       LI   R1,HIBUFF
       MOV  *R9+,R2
       BLWP @VMBR
       CLR  R1                         * Clear pattern index
       SRL  R2,3                       * Get proper count into R2
       MOV  R2,R7
ANM1   MOV  @CLOCK,R3                  * Get clock value into R3
       CLR  R2
       DIV  *R9+,R2                    * Divide by speed factor
       MOV  *R9+,R0                    * Get animation routine into R0
       MOV  R3,R3
       JNE  ANM2                       * If not at interval, skip
       BL   *R0                        * Branch to animation routine
ANM2   AI   R1,8                       * Increment to next character
       DEC  R7
       JNE  ANM1
       MOV  *R8+,R0                    * Write character data 
       LI   R1,HIBUFF
       MOV  *R8+,R2
       BLWP @VMBW
       B    @SUBRET

* Pattern animation data for travel/combat mode 0-6 (56 bytes)
ANDAT0 DATA >0400,104
       DATA 16,ACIRC
       DATA 16,ACIRC
       DATA 16,AUPDW
       DATA 8,AROT
       DATA 8,ASOUTH
       DATA 8,AWEST
       DATA 8,ANORTH
       DATA 8,AEAST
       DATA 4,ASOUTH
       DATA 4,AWEST
       DATA 4,ANORTH
       DATA 4,AEAST
       DATA 32,ACIRC

My old approach was using around 436 bytes of code space. With the data arrays and the smaller routines, my new system uses about 100 less bytes, and is easier to use. On screen, speed seems unimpaired as well. Huzzah!