Subject: [stella] The Seven Year Itch: INV Returns - inv33004.bin From: Erik Mooney <erik@xxxxxxxxxx> Date: Tue, 30 Mar 2004 22:27:12 -0500 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [stella] Lode Runner, KirkIsrael | Thread | |
Re: [stella] Lode Runner, KirkIsrael | Date | |
Month |