[stella] DD RAM usage/animation

Subject: [stella] DD RAM usage/animation
From: Glenn Saunders <cybpunks2@xxxxxxxxxxxxx>
Date: Tue, 21 Jan 2003 05:39:46 -0800
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:
tombstone_RAM ds 44 ; "sloppy" playfield bitmap
P0_Score ds 2 ; BCD
P1_Score ds 2 ; BCD
Timer_Seconds_Remaining ds 1; 1 binary seconds counter
Timer_Jiffy; 1 binary jiffy (frame) counter
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
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:

.byte -1, 0; -1 through -127 can be used in DASM, right?
.byte #FF ; terminator
.byte 1, 0
.byte #FF ; terminator
.byte 0, 1
.byte 0, 0 ; since Y movement is 2 scanlines at a time, add this delay to normalize
.byte #FF ; terminator
.byte 0, -1
.byte 0, 0
.byte #FF ; terminator
.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/

Current Thread