MausGames, on Mon Nov 2, 2009 2:59 PM, said:
I'm not sure what you mean by "19 variables to color player1", how are the colors/variables applied?
Maybe that was worded badly. What I mean is, I'm storing the color table of the player1 sprite in RAM rather than writing it to ROM. I've reserved sixteen RAM colors (p1color_row1 -thru- p1color_row16) that coincide with the 16 lines of a gladiator's shape data in ROM. For instance:
dim p1color = a
dim p1color_row1 = a
dim p1color_row2 = b
dim p1color_row3 = c
dim p1color_row4 = d
dim p1color_row5 = e
dim p1color_row6 = f
dim p1color_row7 = g
dim p1color_row8 = h
dim p1color_row9 = i
dim p1color_row10 = j
dim p1color_row11 = k
dim p1color_row12 = l
dim p1color_row13 = m
dim p1color_row14 = n
dim p1color_row15 = o
dim p1color_row16 = p
For general purpose, I could use this to define to color of each row as a hex or decimal number (i.e. "p1color_row4 = $CA" or "p1color_row4=202") and to perform color transformations in RAM (i.e. "p1color_row4=p1color_row4+2"). But for practical reasons, I reserved an additional three pointers for palette swapping.
dim body_col = var13
dim head_col = var14
dim hair_col = var15
That way, I could just retrieve one color for an enemy's outfit, then perform the gradient color changes (1) dynamically (2) only when necessary. For instance:
body_col = $D4
head_col = $EA
hair_col = $66
p1color_row1 = body_col
p1color_row2 = body_col
p1color_row3 = body_col
p1color_row4 = body_col + 2
p1color_row5 = body_col + 4
p1color_row6 = body_col + 4
p1color_row7 = body_col + 6
p1color_row8 = body_col
p1color_row9 = body_col + 2
p1color_row10 = body_col + 4
p1color_row11 = body_col + 4
p1color_row12 = head_col
if sprite2dir = 0 then p1color_row12 = hair_col
if sprite2dir = 1 then p1color_row12 = hair_col
if sprite2dir = 7 then p1color_row12 = hair_col
p1color_row13 = head_col
if sprite2dir = 0 then p1color_row13 = hair_col
if sprite2dir = 1 then p1color_row13 = hair_col
if sprite2dir = 7 then p1color_row13 = hair_col
p1color_row14 = hair_col
p1color_row15 = hair_col
p1color_row16 = hair_col
MausGames, on Mon Nov 2, 2009 2:59 PM, said:
If you are not using the hidden playfield row at the bottom, you can use those playfield variables to track your player x/y coordinates. You are right that horizontal orientation can be done with a bit instead of a whole byte, so that will save you at least one. There is also a spare AUX variables I think.
I've been reorganizing and squeezing things down this week, and have found a bit more RAM. I think the "ideal" situation would probably be to define the final five rows of player1's shape data in RAM as well, to free up some additional ROM in my last bank, while adding additional flexibility to the player1sprite.
Cheers,
Jarod.
Edited by jrok, Mon Nov 2, 2009 3:33 PM.
1
Well, not really. I reserve 19 vars to color player 1. Then there's four to track the XY positions of the two flickered players, four more to store their last known XYs and another four to track their playfield positions. Two more to track the direction each sprite is facing, and one to track the current animation frame of the sprites. So that's 34 variables right there just to get multicolored gladiators moving around the screen. 
If more Vox's go on sale, I might pick one up as a Christmas present to myself (along with Juno First).
.
