AtariAge Forums: AtariAge Forums -> SpiceWare's Blog

Here's a test of using the SCORE setting (bit D1 of CTRLPF) to colorize playfield drawn kings. I suspect I'll want to swap the scores (1 with 4 and 2 with 3) to break up the colors in the corners a bit.

Here's the source for the current version:
 Medieval_Mayhem_2006_03_09.zip (3.96K)
Number of downloads: 78

I decided to roll my own Warlords instead of hacking the original so that we can have cartridges made

I spent a few hours tonight and have got the score going. The score's going to be on a single line to allow me to have a larger playing area.



The scores make more sense if you know how my players will be set up.

Player 1 = Top Left
Player 2 = Bottom Right
Player 3 = Top Right
Player 4 = Bottom Left

Warlords has some extra logic to deal with Player 2 sometimes being the Top Right Shield(3 & 4 player games) and sometimes being the Bottom Right Shield(2 player games). I plan to not rearrange the players.

I made some more changes to the Edit Mode file and am pretty happy with how it works. All the 6502 opcodes highlight as keyword1, DASM commands as keyword2 and the constants for all the Atari specific variabels as keyword 3. Numbers correctly highlight for hex using $ format and binary with %. I included octal rules, though I don't know if DASM supports octal or not. Numbers starting with 0 are traditionally considered octal so 012 = $0A = 10.This will probably be it on jEdit for a while so I can get back to documenting Warlords.

I started messing around with jEdit to see how it well it would work for coding an Atari game. I've begun writing the syntax highlighting rules(the attached xml file) that currently highlight as shown in the screen capture.To use the syntax highlighting, put the assembly-6502.xml file in the MODES directory of jEdit. Then edit the catalog file in the same directory and add the following.

<MODE NAME="assembly-6502"	FILE="assembly-6502.xml"    FILE_NAME_GLOB="*.asm">

I had to disable the assembly-x86 as it also uses *.asm for the file extension. I disabled it by changing its entry as follows(removed the *)

<MODE NAME="assembly-x86"	FILE="assembly-x86.xml"    FILE_NAME_GLOB=".asm" />

There's a FIRST_LINE_GLOB mode selector that I think should be able to pick up on the PROCESSOR 6502 line(provided it's the first line in the file), but I haven't gotten that working yet.

Didn't get as far as I'd like due to being laid up with a sinus infection; but, I'm down to 2 RAM variables to decipher and have 125 labels renamed with 197 to go.

I'm down to 8 RAM variables to decipher and have 108 labels renamed* with 214 to go.A couple interesting finds1) each player's paddle is only read every 4th frame. There's a couple subroutines, that I named SmoothXmotion and SmoothYmotion, that are used to smooth out the motion over the 4 frames between paddle readings. As a test I changed subroutine to NOP the smoothing and the motion was very jerky.2) Paddle usage had me confused for a little bit a) Paddle 2(INPT1) controls either the purple shield or the blue shield depending on the number of players. b) The Green Player uses Paddle 3(INPT2) - but is only human controlled during a 4 player game. Instead, paddle 4(INPT3) becomes active during a 3 player game.* labels generated by distella are of the format LMMMM where MMMM is the memory location of the ROM. Renamed labels are more human understandable - such as StartOfFrame instead of LF047.

During the Vertical Blank the program converts the paddle reading to x-y sprite coordinates as well as setting the X sprite position of the top players and calculating the X positioning values for the bottom players. However, the sequence isn't in the correct order. It's not a major deal, unless you have captured a fireball. If you're holding a fireball then you run the risk of killing yourself even if you've not lost a single brick!The program does the following:1) Positions the X position of the top players2) Precalculates the X position of the bottom players3) Converts all paddle readings to X-Y values4) starts drawing the visible portion of the screen, where the Y values are used.The problem occurs when you(as the yellow player) are all the way to the lefthttp://spiceware.org/albums/Misc/All_the_way_Left.pngAnd you're trying to move all the way to the right to attack the opposite playerhttp://spiceware.org/albums/Misc/All_the_way_Right.pngThe problem...

I'm working on enhancing Warlords for the 2600. I plan to convert it to 8K then start hacking away. I'm currently on step 1 and have attached the source with my first weeks worth of commenting in case anybody would like to review it.1) Document Source2) Convert to 8K3) find RAM for new routines (rewrite of wall routines should free up 32 bytes)4) Hack away - changes in no specific order:

• The Launch Dragon
• More angles on the fireball
• Game Variation - Multiple Fireballs Options to implement:1 - flicker ball (least likely to be viable - but very easy to try out)2 - flicker player graphics as shield/king, use missiles for fireballs3 - use playfield to draw king, use missiles for fireballs - may have issues with "king color"
• Game Variation - Masochistic ModeCause damage your own Wall if you hold the fireball for too long
• Game Variation - Builder ModeAbility to repair your Wall, but only when others are holding a fireball.