>I might not have made myself clear before. Your game "reminds" me of Prisonball. It's different in that you don't have solid walls.
Yeh, yeh, I got that and I'm certainly not above steal-uh-borrowing gameplay elements from other games... (smile)
>It's similar to Breakout turned on it's side played by 2 people. The object is to score the most points in 5 minutes. There are 3 balls. Each time a ball hits your paddle you "own it". So when it hits the bricks you score points. Everytime a wall is distroyed it will refill. So to get the most points you would want your ball to get trapped between 2 walls (preferably the black and blue walls). The score break down is 1 point for the white wall, 3 points for the blue and 5 for the black.
Okay, got it. In 2 player mode, mine will be a similar game except the goal of my game is more ponglike - to score goals on your opponent. I would have liked to incorperate some Breakout elements so that on some levels bricks could be knocked out. But it would introduce a couple big problems. First would be that it would gobble up a bunch of RAM which I don't really have to spare (48 bytes (2 bytes per row of bricks) unless I decreased the size of the interior). Second it would really screw up the timing of the display kernal which is actually pretty tight. Right now, the interior pattern of walls comes from ROM and it's symmetrical. So it only needs a single write to PF2, adding a second read then write to PF2 would be really tough.
Well, maybe if I eliminated the indexed reads and read directly from RAM. No, then my code gets huge and it's only going to save me a couple cycles on that one LDA. Ummmm, at this point I don't think so.... I suppose I could sacrifice variable ball size but I dunno if that's really going to help either.
Here's the current kernal for the middle rows of the screen and you'll see what I mean by tight.
sta WSYNC
lda #p0colour ;2
sta COLUPF ;3
lda (leftpf1),y ;5
sta PF1 ;3
lda (center),y ;5
sta PF2 ;3
txa ;2
sbc drawnball0y ;3
cmp drawnball0size ;3
lda #wallcolour ;2
sta COLUPF ;3
lda #1 ;2
adc #0 ;2
sta ENAM0 ;3
lda (rightpf1),y ;5
sta PF1 ;3
txa ;2
sbc drawnball1y ;3
cmp drawnball1size ;3
lda #p3colour ;2
sta COLUPF ;3
lda #1 ;2
adc #0 ;2
sta ENAM1 ;3
inx ;2 71 cycles
leftpf1 and rightpf1 are pointers to the current "bit patterns" of the left and right
players paddles.
center is a pointer to the bitpattern of the central playfiel area.
Register X is the current scanline.
Register Y is the current row of bricks (This kernal is repeated 6 times for each Y value)
Other variables should be self-explanitory.
I have a couple cycles left, I was planning to may use them to turn the various colours into variables (particularly the interior walls at any rate).
I could maybe change
lda (center),y ;5
sta PF2 ;3
to
lda center1,y ;4 ABS,y
sta PF2 ;3
and add a second
lda center2,y ;4 ABS,y
sta PF2 ;3
But the net cost is 6 cycles and because I'm using a reflected playfield that second PF2 write is going to have to be perfectly timed (is it even possible?). If I switch to a copied playfield, then it just gets worse since I have to write to PF2 (left) and PF0 (right) and PF1 (right). Ugh!
I could also switch these:
lda (leftpf1),y ;5
sta PF1 ;3
to
lda leftpf1,y ;4
sta PF1 ;3
And save a couple cycles, but again at the cost of a bunch of RAM that I don't have.
Anyway, barring a sudden brainstorm, I think it's going to stay pretty much the way it is...
Chris...
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
