Subject: Re: [stella] Trick12 - inv3.bin - inv3.a|
From: Erik Mooney <emooney@xxxxxxxxxxxxxxxx>
Date: Tue, 13 Mar 2001 21:35:28 -0500
On Mon, 12 Mar 2001 21:18:52 +0100, you wrote: >Erik Mooney wrote: >> Would now be the time to show everyone this? I've actually been sitting >> on it for a couple years or so, wondering if I'd ever get around to >> finishing it. The tricky part is not drawing the 11 x 5 grid, it's being >> able to turn on and off each individual invader. There is definitely no >> time on scanlines occupied by invaders to draw missiles, BUT there _is_ >> time on the scanlines between rows of invaders -- a missile can be turned >> on at that time and then turned off during the next gap. > >Hey, THIS is ultra extra super cool!!! > >Why did you stop??? Everybody is waiting for a *real* >Space Invaders for the 2600. This thing was actually the nail in the coffin on the first INV. There was no point to finishing the playfield-graphics one after being able to do this one; but I didn't (and still don't) want to basically redo all the work I'd done on the first one in this one. And I felt kind of like a bum about that, which is why I never shared this before. >> Let's see if anyone can figure out how I did this without looking at the >> binary, or even with looking at the binary :) > >Ok, I couldn't resist, cheated and looked at the code. >I always loved self-modifying code, and this is a very >good way to use it. Yup. How do you make a store/no-store decision in zero cycles? Make the decision ahead of time by self-modifying code in RAM. >I think it might be even possible to reduce the amount >of RAM used (48 bytes) down to 33 bytes, if you remove >the QWSYNC and mix RAM and ROM in the kernel loop. > >So I'm looking forward to see a first working demo from >this :) I don't expect to go much of anywhere with this; it's been in its current state for a couple years actually. >And please, post some source too :) Here it is. The other tricks were to get single-pixel positioning of the invaders. It does that by self-modifying code to get single-cycle (3-pixel) precision. Then, each of the sprites is actually 6 pixels wide within an 8-pixel player graphic, so there's three different copies of the graphics stores at different alignments within the 8.
Description: Binary data