At 07:13 PM 1/20/2003 +0100, you wrote:
Currently this still doesn't fit well into the existing kernel, but I
already know how to save 11 bytes and with some compromises we might
even get the whole 22 bytes.
When you say save 11 bytes do you mean RAM or ROM? I'm just trying to find
out whether the packed-playfield is going to happen or not.
I thought I wrote this from Hotmail but I didn't see the message show
up. Anyway, if the timing issues have to do with tearing, as always, we
can fall back to the missiles only extending to the width of the safe-zone
strip and worst-case, cheat the safe-zone in one playfield pixel.
One drawback of the packed playfield is that I'd no longer be able to do
the title screen, at least not by loading it into RAM. I'd have to have an
alternate kernel just for that. Since we might have to drop the title
screen anyway to save resources I'm not that concerned about it.
I'm also thinking about maybe dropping the visible timer and going with the
blinking sprites warning signal like Combat and other timed 1st gen games
do. That might save some space, though probably not much in the way of RAM.
How much RAM do you think the stack is taking up in the game currently?
I'm thinking we'll need at least this much RAM for the rest of the game:
;Playfield
tombstone_RAM ds 44 ; "sloppy" playfield bitmap
;SCORE
P0_Score ds 2 ; BCD
P1_Score ds 2 ; BCD
;TIMER
Timer_Seconds_Remaining ds 1; 1 binary seconds counter
Timer_Jiffy; 1 binary jiffy (frame) counter
;ANIMATION
M0_Anim_Table_Index ds 1
M1_Anim_Table_Index ds 1
P0_Anim_Table_Index ds 1
P1_Anim_Table_Index ds 1
;game state
Variation ds 1
P0_State ds 1 ; crashing, speed
P1_State ds 1 ; crashing, speed
Grenade_Type ds 1; table lookup for color/width
Sound_effect_1 ds 1;
Sound_effect_2 ds 1;
P0_COL ds 1 ; for blinking or color/bw mode
P1_COL ds 1 ; for blinking or color/bw mode
;Controller
LastSWCHA ds 1
CurrentSWCHA ds 1
Console_Debounce ds 1
64 bytes
+ ~36 bytes used in your current build:
100 bytes
If we keep stack usage less than 8 bytes that gives us 20 bytes of RAM
beyond what is estimated here.
Sounds doable still.
It's just that I hate leaving every other bit of playfield RAM unused
everywhere but in the title screen.
Seems like a real waste. But if it's necessary for timing purposes I guess
it's okay.
BTW, the method I'm thinking of using for animation is to have a lot of
little tables to sequence out the X/Y delta like so:
Zombie_Left
.byte -1, 0; -1 through -127 can be used in DASM, right?
.byte #FF ; terminator
Zombie_Right
.byte 1, 0
.byte #FF ; terminator
Zombie_Up
.byte 0, 1
.byte 0, 0 ; since Y movement is 2 scanlines at a time, add this delay to
normalize
.byte #FF ; terminator
Zombie_Down
.byte 0, -1
.byte 0, 0
.byte #FF ; terminator
Zombie_Diagonal_Left_Down
.byte -1, 0
.byte -1. 0 ; moving left twice to match the Y delta due to Y being 2
scanlines at a time
.byte 0, -1
.byte 0, 0
.byte #FF ; terminator
Then how often these offsets are applied will determine the speed, the
maximum speed being reached when these values are applied every
frame. Beyond that I would have to double the offsets (like shifting gears
in a way).
This should work okay for vector-like movement. Doing the physics for the
cars will be trickier if I want any sort of inertia/centrifugal glide and
slide during hair-pin turns. I don't think the coin-op featured this but I
think it would enhance the game. Could be a variation or difficulty switch
option.
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
