[stella] The Seven Year Itch: INV Returns - inv33004.bin

[Erik Mooney <erik@xxxxxxxxxx>]

After I posted my DASM question to the list, Albert Yarusso emailed me
privately notifying me about royalties from INV purchases on AtariAge.  At
that moment, it finally really registered with me that this game was out
there for sale, and people are buying it, probably unaware that it was
never really finished.  That bothered me enough that I couldn't work on a
new 2600 project with a clear conscience.

So here it is.  Seven years later, INV is at last complete.

I'm open to suggestions for tweaks and polish, but not for new features.
The chief reason that initially made me stop working on this was that I
thought it was close to done, but there were so many features and game
variations that could be added that I got overwhelmed thinking about them.
I do NOT plan to add any new features to the game now.  It's complete to
where it recreates the arcade Space Invaders as well as I can do from this
code-base, plus two-player simultaneous play.

Things that I might still do:

- rework the player-death sequence to match the arcade, if that seems
worthwhile

- proper PAL timing and colors (switchable with B/W switch); can someone
point me to a good reference on the colours?

- fix any genuine bugs

It works on Z26 and PCAEWin.  I tried to test on a real 2600, but it seems
my 2600 power supply has died and I'll have to dig up another.  (The
machine boots up for 1-2 seconds and then the picture fades briefly before
cutting out entirely.  A multimeter shows the supposedly 9VDC power supply
is putting out 14.5V...?)  If anyone wants to test it, feel free, though
it always worked before and I didn't mess with the vertical timing and
I'll test it myself when I can.


The change-log:

Invaders now score properly.  10 points for the first two rows, 20 points
for next two, 30 for top row.

Saucer also scores properly.  300 points if you shoot it with your 23rd
shot on a board or every 15th shot thereafter.  I wasn't able to find
documentation on the exact sequence for scores other than 300.  I set it
up as arbitrarily 50, 100, or 150 (it is deterministic based on your
number of shots, not random.)

Scores are displayed in each player's color, and player 2's score is black
if it's a one-player game.

True saucer timing: it comes out every 25 seconds until fewer than 9
invaders remain.

The starting position of the invader formation on each board properly
matches the arcade, reaching a maximum at wave 7 and resetting to the
first wave position in wave 10.

Invader bombs damage shields properly.

Added extra life at 1000 points



Some other thoughts:

I must've gotten better at programming somewhere over the last few years.
The specific problem that made me balk the last few times I tried to
resume development on the game was making the invader bombs damage the
shields.  The invader bombs were stored with their X-coordinate only in
FC_X fine/coarse format, not the real X-coordinate value.  The real X
coordinate is needed to determine which column of the shield to damage.
Three or four times before, I'd looked at that problem, and tried to come
up with a fancy algorithm to convert FC_X back to straight X, but never
solved that.  This time, I saw the real solution instantly.  I just
grabbed two extra bytes of RAM to store the real X coordinates, and the
whole algorithm took 20 minutes to code.

I had to untangle a bit of Piero's modifications, to be sure.  Took me a
good 20 minutes of mentally tracing the code until I realized he had tied
together the collision detection for bomb-hitting-shield and
bomb-hitting-player.  I had to break that out into separate handlers, as
the logic for each case is totally different, of course.

My other moment of boggling at Piero's code came when I figured out his
mechanism of making the saucer appear.  There was a LDA InvLeft followed
by an AND #%00001111.  Okay, that would seem to prevent the saucer from
appearing when 15 or fewer invaders are left, making the test by checking
for 0000 in the top four bits instead of using a CMP.  But I couldn't
figure out how he kept track of the time until the saucer was due to
appear again, and there were no calls to the random-number routine there
either.

Turned out that he didn't keep track of time at all.  The AND statement
made the saucer appear whenever the number of invaders left ANDed to 1111
- in other words, the saucer would appear whenever 45, 30, or 15 invaders
were left!  And it'd appear repeatedly endlessly when one of those magic
numbers was present.  I corrected all that with a proper timer that does
the arcade rule of 25 seconds between saucers, and no saucers when 8 or
few invaders remain.


Anyways, the state of development tools has come quite a ways since 1997.
I used to do all my coding from the DOS command-line, in DOS EDIT, with
batch files to run DASM and PCAE.  Reloading EDIT and paging down to line
1873 when DASM reported an error used to be a tremendous chore.

For this run of development, I took the time to set up Textpad with
hotkeys for DASM, Z26, and PCAEWin.  I was shocked when Textpad was able
to automatically recognize line numbers in DASM's output and jump to the
line with the error when I double-clicked on it!

Also, I must convey how wonderful it is to have PCAEWin, its debugger, and
the source code all visible simultaneously in multiple windows.  I used to
spend 10 minutes per bug just memorizing or scribbling down the relevant
source code and memory locations so I could match it up with the PCAE
debugger displays.  This is SO much smoother than in the old days.  Also
very helpful are all the DASM tricks that have been rediscovered and/or
implemented, like letting it count memory use for you.  Thanks to all the
authors of those tools!  (Now if only PCAEWin accepted a filename as a
command line parameter... :) )

- Erik

Attachment: inv33004.bin
Description: Binary data