Re: [stella] Trick12 - inv3.bin - inv3.a

[Erik Mooney <emooney@xxxxxxxxxxxxxxxx>]

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.

Attachment: inv3.a
Description: Binary data