ErikM

Thanks for the video, glad you like the game! I put quite a bit of effort way back when into accurately replicating the mechanics and speed and timing and sound of the arcade SI to get the right feel, nice to see that's still appreciated

INV programmer here, I'm watching this thread too for any more comments or questions about the game.

Hi. INV+ programmer here, dos486.com is my site. INV+'s source code is just a text file. The ".a" extension doesn't mean anything and isn't any kind of standard, that was just my own choice to mark Atari code separate from PC x86 assembler code (".asm") that I was also doing at the time. DASM and the other assemblers don't care what the file extension is, they will take any file containing text. Yes, .bin files are the machine code to run on an emulator, or on a real Atari with the help of some kind of development cartridge that it can be loaded onto. Yes, BombDelay and all those other lines are just defines, they are defining names for memory locations. I am not promising that INV+'s code is any sort of good material to learn from. There are much better tutorials out there than my 18 year old mess of a game.

Erik here, INV+ programmer. I just came across this thread. Always neat to see that work still active in the community. 8930 is amazing indeed, what was that, at least 8 invader waves? I never scored more than 3000 or so myself, though I was always looking for bugs more so than seriously score attacking.

I started from scratch, not anybody else's code (well, there's vestiges of tutorial stuff like Nick Bensema's "How to Draw a Playfield".) I don't know about anyone who worked on it after me, if Piero did anything or if it was based on my code or not.

> four independent detailed player-controlled flickerless objects on the same scanline. That part does work, as I remember. Not perfectly, since the register hits happen throughout the scanline so there'd be some graphical jitter. It's the loop at K00 in the source. The rest of the kernel was to be basically two simultaneous streams of Kaboom's bombs. The challenge is to reposition either sprite while still writing the other's graphics every scanline or two, and also reading the four paddles. That's the code at Kernel that can branch to DoBomb0 or DoBomb1. I don't think that part ever worked. I don't have any of your emails or biglist posts, that was all on my college email account which is long gone.

Hi. Erik here. I do remember this. The kernel wasn't anywhere near completed. I've actually still got the code, although it doesn't seem to work. Z26 and Stella both show it rolling the screen like crazy so there's really nothing to see. Here it is, maybe you can get some closure out of it. As for disappearing on you, I just got busy with school and work and lost interest in 2600 programming. No elaborate tale there, I'm afraid. - Erik TANK.TXT TANK.BIN

Old thread, but I just now thought to visit Atari Age for the first time in a long while. The timing of the shots in INV+ is entirely intentional, to match that of the arcade Space Invaders. I can appreciate that some might not like it. There is an adjustment available with the difficulty switches - A means you have to press the fire button once for each shot, B means you can hold it down and it will autofire (after the intentional delay.) And yes, the invaders are blocky. They are not sprites; they are drawn with the same low-resolution playfield mechanism that makes up the walls in Breakout and mushrooms in Centipede and so on. I was going for the fully accurate arcade gameplay, compromising on the graphics to do it. (Back in 1997 when I started INV, we had no idea how to do the tricky rapid hits on sprite registers to get 7 or 9 or 11 sprites per line.) By the way, now might be an appropriate time to reveal the Easter Egg initials hidden in INV+. Try hitting the saucer with your very _first_ shot of the game!

There's no separate PAL version for INV+. It's a single binary that supports all of NTSC, PAL-50, and PAL-60. To cycle between the modes, flip the Color/B&W switch down and up.

To my knowledge, INV+ is the first game to support three-way switchable video modes. It has standard NTSC, and also has PAL modes for both 50 Hz and 60 Hz. The former allows the game to display and play on PAL TVs that can't sync to 60 Hz, while the latter allows correct colors on PAL TVs while maintaining the 60 Hz gameplay speed. The third mode of PAL 60 Hz isn't necessary for games that make the gameplay speed independent of the TV frame-rate, but it's a good solution for games where conversion to nonsynchronous game timing would be difficult or impossible.

The invaders in INV+ are drawn with the console's playfield graphics, not the sprite graphics. If you're not familiar with the 2600's technical capabilities, just know that it's the same mechanism used to draw such things as the walls in Breakout and "mushrooms" in Centipede. The resolution available with playfield graphics is very low, of course, but that's just about the only way to get a full rack of 11 x 5 objects on the 2600. The homebrew Space Instigators uses a very intricate hardware trick to get 9 invaders per line. That trick is actually extendable to 11, but has some problems; either the invader formation has to be very wide (almost the entire width of the screen), or you get display artifacts with the spacing between invaders becoming uneven. So it's gameplay, not graphics, that drives INV+, of course. I took care to replicate as many other aspects of the arcade SI as possible. The 11x5 invader formation is a big part of the gameplay, of course, and there's several other details that match the arcade. Examples are the fact that invaders don't shoot in the last row before landing, and that the starting position of the invaders requires them to advance 11 times to reach Earth on the first level and one row closer in waves 2, 3, 4, and 7. Also, the saucer appearance, behavior, and scoring are dead-on for the arcade, an aspect where Instigators falls short.

Heh, that's my original code from way back when (1997), that I originally wrote for INV. Funny how things can come full circle. The advantage of the 32-bit version over a shorter one is that it's less prone to artifacts in the distribution of the output. For example, if you pull an 8-bit random number from an 8-bit LFSR, you can never get zero. One easy way to seed any shift-based RNG is to just simply call it once per frame whether or not you need a random number. Unless the user manages to press Game Reset on exactly the same frame after every bootup, you'll get a reasonably random initialization of the sequence.

NE146, I saw your first post last night but didn't have time to reply then. Glad you got a chance to test it more. Your observation is right - you can't fire again until after the invader finishes exploding. This is intentional, of course - the player's missile graphic is also used to animate the explosion. There is also a delay even after that, that could be shortened, but I like it as-is. I'm no longtime veteran of the arcade SI, but I played it a fair bit in MAME while working on INV, and that delay is present in the arcade SI as well (or at least on my MAME.) I'm doubly blown away now by it especially with the extras such as shot counting, and point value of the ufo's being shown amongst others. Well, those are supposed to be basic parts of the game, not really "extras", I just never got around to coding them before. The real "extras" over arcade SI are two-player simultaneous play and the invisible-invaders mode. If this gets sold in cart form, count me in. Al covered that one.

If nobody else has any comments or suggestions, I'm going to move ahead and release it this weekend.

The shot timing is intentional. If you load up the arcade Space Invaders in MAME, you'll see that it behaves that way too. Overall, I'm quite satisfied with the playability of this game. IMO, it compares quite favorably to both the arcade SI and the 2600 Space Instigators.