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 > STA ENAM1 > >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 player.) LDX Scanline LDA MissileEnableData,X AND #$0F TAY LDA PlayerGraphics,Y STA GRP0 LDA MissileEnableData,X LSR LSR LSR STA ENABL LSR STA ENAM0 LSR STA ENAM1 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 http://www.biglist.com/lists/stella/archives/ E-mail UNSUBSCRIBE in the body to stella-request@xxxxxxxxxxx to be removed.