Subject: Re: [stella] Collaboration From: Thomas Jentzsch <tjentzsch@xxxxxx> Date: Sun, 19 Jan 2003 20:48:46 +0100 |
Glenn wrote: > But the former is more of an issue. I'd be happy if the 2nd scanline > was _always_ white if you wanted to make it easy on yourself. I have commented this problem in the code. Making the second scanline always white looks like the only solution. Just add lda #$0e sta COLUPF before the "; disable grenade:" comment and reduce the following SLEEP from 9 to 4. > In BARRIER mode the color tearing might be inevitable I guess unless > you blanked those lines. No, instead of loading #GRENADE_COL you could load a variable containing GRENADE_COL or BLACK and decrease the following SLEEP. But then you will limit the grenade a little bit more (3 pixels) from the left. > The other issue is in relation to vertical wrapping. Skipdraw will not > allow for the sprite to appear on screen more than once, so this will force > a dead zone while wrapping, right? I can deal with this but I have to make > sure the AI doesn't make the zombies hide in there. Right now the sprites > are popping but on one of the previous builds they were wrapping. Can you > make them wrap next? I hope that vertical wrapping will just require some changes to the setup code. Else we would need an extra kernel loop for the top or the bottom. > Also, I noticed that by going to the interleaved missiles, the HMOVE lines > are back to being every other line, so sprites COULD show through. Is the > tearing fixed enough to allow the zombies to extend completely across the > screen? If so we can go back to the safe zones being one-playfield-pixel > in width which will look a bit more authentic. (I would still keep the > cars from extending.) Give the background some color and you will see what has changed. The tearing is nearly 100% removed, only the *very* right you *might* notice some problems with M0. > Also we should be mindful of how much RAM is being used. I see 36 bytes > used so far. > The kernel right now doesn't point to RAM for the tombstones, so remember > that it's going to eat up 44 bytes. So we're already at 80 bytes of > RAM. We're going to need ram for score, sound envelopes, animation, and > more. So it's going to be tight. There are a few variable remains from the single line code (tmpVar2, krnlIdx, vecKernel, 4 bytes in total). And some are only temporary needed for the kernel and can be reused for storing other temporary variables. But you are right, RAM will be tight (as always :-). > Is there any way we can do the tombstones via the Centipede %10101010 / > %01010101 bit-masking trick (where each byte stores two rows of information > since the mushrooms are spaced out and alternate) or is there not enough > time on the 2nd grenade line to set that up? If we could do that we could > gain 22 bytes of RAM. The missiles already eat up a lot of cycles and make the timing very close. There are 6 free cycles in the playfield code, but we would need 8 for doing this: lda RAM1,x and #%01010101 sta PF1 lda RAM2,x and #%01010101 sta PF2 lda RAM1,x and #%10101010 sta PF1 lda RAM2,x and #%10101010 sta PF2 And we would have to start that code at an earlier cycle. There is no space for this at the moment, else we would cause some more tearing at the (very?) right. Have fun! Thomas _______________________________________________________ Thomas Jentzsch | *** Every bit is sacred ! *** tjentzsch at web dot de | ---------------------------------------------------------------------------------------------- Archives (includes files) at http://www.biglist.com/lists/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [stella] Collaboration, Glenn Saunders | Thread | Re: [stella] Collaboration, Thomas Jentzsch |
Re: [stella] VCS Hard Drive, PDAs, Glenn Saunders | Date | Re: [stella] Collaboration, Albert Yarusso |
Month |