Re: [stella] MultiSpriteDemo update (source+binary)

Subject: Re: [stella] MultiSpriteDemo update (source+binary)
From: emooney@xxxxxxxxxxxxxxxx (Erik Mooney)
Date: Wed, 09 Apr 1997 19:36:42 GMT
>> >CLC
>> >ADC #252        ;If 0 <= A <= 3, the carry will now be clear.
>You can save two cycles by:
>   ADC #251        ; if MissileY >= ScanLine, carry is set, so adjust by 1

I did that further down in my post =)

>I missed the original conversation, but you're probably aware that
> AND #$FC        ; If 0 <= A <= 3, the Z flag is now set.
> PHP             ;Plug it into ENABL.
>is what Combat does, but it's limited to powers of 2 for the missile
>height (its missiles are 2 high so use AND #$FE.)

Combat's missiles are 2 high?  It looked like 1 to me.. but you are right,
AND #$FC will set Z easily (certainly easier than CMP #4 / LDA #00 / ADC
#00 as I was doing.)

>If you're using a Supercharger and can afford the RAM (if cycles are
>incredibly hard to come by compared to memory):
> LDX ScanLine
> LDA MissileEnableData,X
>which would also allow missiles to be enabled/disabled in multiple
>locations on the screen.

That's a possibility, even on a standard game with 128 bytes RAM.  Multiple
objects could easily be stored in different bits in the byte... and
pointers to player graphics could also be done, with 15-line high players
(the first line of the player graphics must be zero, to allow disabling the
LDX Scanline
LDA MissileEnableData,X
AND #$0F
LDA PlayerGraphics,Y
LDA MissileEnableData,X

As written, this only allows one player, but you could fit pointers to two
7-line high players along with enable/disable bits for two missiles or one
ball and one missile in the one byte of RAM.  You could also allow multiple
copies of players by adding NUSIZ values in ROM.. such as LDA
PlayerCopies,Y / STA NUSIZ0 after the STA GRP0 above.

Unfortunately, the stock 2600 doesn't quite have enough storage to do
this... but if your game kernel is only, say, 160 scanlines high (leaving
space for scores, radar, "copyright Activision" etc) and you only run this
block every two scanlines, using the vertical delay registers for vertical
positioning.. you could do this in 80 bytes, or about 2/3 of your total
memory space.  This would also leave time during the alternate scanlines to
rewrite the playfield or reposition objects.  This RAM is also needed only
during the drawscreen kernel, so the RAM could be reused in other places -
one example that comes to mind is drawing the screen, then use a 4-8
scanline gap to set up pointers to six score digits (reusing the video RAM)

Essentially, I've invented video RAM for the 2600 here.. this could be
important.  This could make it *much* easier to program games with moderate
sprite reuse (say, River Raid, Chopper Command.)

Archives available at
E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.

Current Thread