Space Invaders Arcade

[Thomas Jentzsch]

I needed a break from other coding. Therefore, when @ZeroPage Homebrew announced that they would play INV+ (and show a demo named INV3), I remembered an old Space Invaders demo which I had done in 2001 and 2003. Using the RESP trick, I was able to display 11 invaders per row, like the arcade game. 

 

So I went back to the demo and decided as an intermediate project I might make a nice little (4K) game out of it. Over the past days I have completed the overall display kernel. This gives a good impression about the final game. It even has basic gameplay as you can shot the invaders. However there are still some major things missing, e.g. the invader bombs, the shield handling and all sound.

 

I based the graphics on the arcade version and adapted them to the different screen layout. They are not perfect, but for now they should do. For the colors I decided go for a medium arcade variant (early versions had no colors, later versions were very colorful).

 

The obvious differences to the arcade are:

- The invader formation is much wider than in the arcade, this is a hardware limitation 

- There are 3 instead of 4 shields, because I can do only 3 large shields (if anyone has an idea for 4 large screens, please let me know) or 4 small shields (like in Atari's Space Invaders game). IMO the larger shields are closer to the arcade. What are your thoughts here? 

 

BTW: "Space Invaders Arcade" is only the project name until I come up with something better. 

SIA V0.1 (Thomas Jentzsch) (NTSC).bin

SIA V0.2 (Thomas Jentzsch) (NTSC).bin

SIA V0.3 (Thomas Jentzsch) (NTSC) (F8SC).bin

Edited June 15, 2020 by Thomas Jentzsch

[+Karl G]

It looks great so far, and I think the three large shields should be fine, personally. It would be nice to have an option for more or less colors. I am not personally an arcade purist, and I would love to see each row of Invaders be a different color.

[+Andrew Davie]

Lovely. A few bugs, like invaders generating from nothing on the bottom row when you shoot. But great start and I'd love to see this completed.

Invaders has been a holy grail - particularly in the '90s - and this is looking better than most already!  The 3 bases are fine by me.

 

[Thomas Jentzsch]

27 minutes ago, Andrew Davie said:

A few bugs, like invaders generating from nothing on the bottom row when you shoot.

When exactly does that happen? When the shields are gone or before?

[Thomas Jentzsch]

49 minutes ago, Karl G said:

It would be nice to have an option for more or less colors. I am not personally an arcade purist, and I would love to see each row of Invaders be a different color.

Here are shots from the three original variations:

And how they achieved the colors:

They are using color overlays, so the colors are fixed to certain areas. The Atari 2600 is more flexible here. 

 

So I could either make the colors follow fixed overlays or follow the elements (so an invader rows keeps its color when moving down). And I could use the original colors or make up my own ones. There are plenty of options.  

 

Making them switchable might be possible (if I have enough ROM).

 

[+Andrew Davie]

2 hours ago, Thomas Jentzsch said:

When exactly does that happen? When the shields are gone or before?

Before. I can consistently get it to happen on the left shield, near its inner left edge. Just firing repeatedly brings up a ghost invader which keeps generating and getting hit, and the invaders all stomp down a row (from memory).  Anyway, it was fairly easy to reproduce and I'll try and get you a screen video cap of it sometime.

 

[+Andrew Davie]

Here we go. I caught it on "video". Bug occurs towards the end of the "clip" but I included it all so you can see what I did.

 

[Thomas Jentzsch]

I see, thanks. That's a shield collision misinterpreted.

 

Once I get the shields going, this should be fixed.

[+sramirez2008]

5 hours ago, Thomas Jentzsch said:

Making them switchable might be possible (if I have enough ROM).

This would be great, however, I actually prefer your first screen. The three shields is not an issue.
 

Thank you for deciding to continue with this.?

[TrekMD]

That looks fantastic!  Thanks for sharing this!

[djmips]

fantastic work! 4K!! wow

[+mksmith]

Looking great so far!

[+Muddyfunster]

Wow, this looks really nice.

[+Nathan Strum]

8 hours ago, Thomas Jentzsch said:

So I went back to the demo and decided as an intermediate project I might make a nice little (4K) game out of it. Over the past days I have completed the overall display kernel. This gives a good impression about the final game. It even has basic gameplay as you can shot the invaders. However there are still some major things missing, e.g. the invader bombs, the shield handling and all sound.

 

I based the graphics on the arcade version and adapted them to the different screen layout. They are not perfect, but for now they should do. For the colors I decided go for a medium arcade variant (early versions had no colors, later versions were very colorful).

That looks great!

 

Now, I don't know if this could be done in 4K, but while working on Gorf Arcade with John, I thought, "Well... as long as I've got some Space Invader sprites done..." I mocked up a Space Invaders Arcade screen that would incorporate more of an arcade-like background (the player's ship is still from Gorf in this pic):

 

 

You're welcomed to the sprites if you'd like (John said it would be okay with him), and the background if it's of any use.   

 

- Nathan

 

P.S. I was nagging John to include a "hidden" Space Invaders Arcade Easter Egg in Gorf, but there wouldn't be enough ROM to do it. Plus, John didn't really want to have to program six games for one cart.  

[+sramirez2008]

10 minutes ago, Nathan Strum said:

 

You're welcomed to the sprites if you'd like (John said it would be okay with him), and the background if it's of any use.   

 

- Nathan

 

P.S. I was nagging John to include a "hidden" Space Invaders Arcade Easter Egg in Gorf, but there wouldn't be enough ROM to do it. Plus, John didn't really want to have to program six games for one cart.  

Oh baby! Now I can’t wait for both of these games.

[+Gemintronic]

Just wondering about the challenges in drawing 4 shields.  What are possible solutions?

[Omegamatrix]

It would be nice for each row to have a different color. Maybe you could turn them all white with B&W switch.

 

I think the 3 shields is fine. They have good coverage.

[+sramirez2008]

28 minutes ago, Omegamatrix said:

Maybe you could turn them all white with B&W switch.

This would be appropriate?

[+D Train]

5 hours ago, Nathan Strum said:

Plus, John didn't really want to have to program six games for one cart.  

oh, boo hoo!  what a big baby!

 

[djmips]

Keep it arcade perfect, ignore the people who want color. If they want it original they can just tape cellophane to their TV.

Edited June 12, 2020 by djmips

[Thomas Jentzsch]

10 hours ago, Nathan Strum said:

Now, I don't know if this could be done in 4K, but while working on Gorf Arcade with John, I thought, "Well... as long as I've got some Space Invader sprites done..." I mocked up a Space Invaders Arcade screen that would incorporate more of an arcade-like background (the player's ship is still from Gorf in this pic):

 

You're welcomed to the sprites if you'd like (John said it would be okay with him), and the background if it's of any use.   

That background is looking great. I had not thought about one and at least during the invader display (which ranges the whole screen, except for the score and bottom line) there is currently no free cycle left. So chances a very small. 

 

The sprites look fine, but I need them taller (10 pixel). And I intentionally made them as wide as possible (8 pixel), the gap between the columns is already much wider than in the arcade. Still I want to make the top invader narrower (6 pixel) than the other two. That's closer to the arcade and makes it harder to hit.  

[Thomas Jentzsch]

9 hours ago, Gemintronic said:

Just wondering about the challenges in drawing 4 shields.  What are possible solutions?

Until someone comes up with a better idea: drawing four 8 pixel wide shields. These would cover only 32 pixel (and look quite tiny), while my three 15 pixel shields cover 45 pixel.

[+Andrew Davie]

2 hours ago, Thomas Jentzsch said:

Until someone comes up with a better idea: drawing four 8 pixel wide shields. These would cover only 32 pixel (and look quite tiny), while my three 15 pixel shields cover 45 pixel.

Could the shields be PF graphics?  Do invaders/shields EVER overlap?

 

 

[Thomas Jentzsch]

For those who are interested into details, I will try to explain the invader kernel code, which runs in Zeropage-RAM.

 

This is the code which is copied into RAM:

;---------------------------------------------------------------
KernelCode SUBROUTINE       ;               patched into
;---------------------------------------------------------------
.loop                       ;       @61..71
PatchInv = . + 1
    lda     InvaderGfx-1,y  ; 4
PatchHM = . + 1
    sta     HMOVE           ; 3     @68..   bit DUMMY       early HMOVEs!
Patch0
PatchR0 = . + 1
    sta     RESP0           ; 3     @71..   lda DUMMY       1st invader A
Patch1
PatchR1 = . + 1
    sta     RESP1           ; 3     @74..   lda DUMMY       2nd invader A
PatchGRP0
    sta     GRP0            ; 3             bit GRP0
PatchGRP1
    sta     GRP1            ; 3             bit GRP1
PatchMsl = . + 1
    lda     ENABLTbl-1,y    ; 4
    sta     ENABL,x         ; 4     @12..                   waste one cycle
PatchRESP0
PatchR2 = . + 1
    sta     RESP0,x         ; 4     @16..   lda DUMMY,x     1st invader B, waste one cycle
PatchRESP1
PatchR3 = . + 1
    sta     RESP1,x         ; 4     @20..   lda DUMMY,x     2nd invader B
    sta     RESP0,x         ; 4     @24..   lda RESP0,x
    sta     RESP1,x         ; 4             lda RESP1,x
    sta     RESP0,x         ; 4             lda RESP0,x
    sta     RESP1,x         ; 4             lda RESP1,x
    sta     RESP0,x         ; 4             lda RESP0,x
    sta     RESP1,x         ; 4             lda RESP1,x
    sta     RESP0,x         ; 4             lda RESP0,x
    sta     RESP1,x         ; 4             lda RESP1,x
    sta     RESP0,x         ; 4     @56..   lda RESP0,x
    dey                     ; 2
    bne     .loop           ; 2/3
    rts                     ; 6     @66..

As you can see, there are a lot of patch labels (and even more patched addresses). There are basically three groups of patches;

1. Invader graphics and missile enabling table addresses (PatchInv/Msl)
2. Kernel position patches (PatchR1..3, PatchHM)
3. Invader enabling patches (PatchRESP0/1, 11 addresses; Patch0/1)

Now some details:

1. I think this is straightforward and requires no extra information. 
2. The are two RESP0/1 for the two leftmost invaders. If the formation is more to the left, the 1st RESP are use, HMOVE is enabled and the second RESP are disabled (changing address into DUMMY = $2d). Vice versa if is the formation is more to the right. The transition point is different for P0 and P1.
   Note: The fine positioning is done by shifting the kernel timing.
3. If an invader is disabled, the STA instruction is replaced with an LDA instruction (twice for the two leftmost invaders).

This are the patch tables required for patch group 2. We have 11 positions of the formation, so there are 11 values each (some data is overlapping to save space):

PatchHMTbl
    .byte   HMOVE, HMOVE, HMOVE, HMOVE, HMOVE, HMOVE
;    .byte   DUMMY, DUMMY, DUMMY, DUMMY, DUMMY
Patch2Tbl
    .byte   DUMMY, DUMMY, DUMMY, DUMMY, DUMMY, DUMMY
;    .byte   RESP0, RESP0, RESP0, RESP0, RESP0
Patch0Tbl
    .byte   RESP0, RESP0, RESP0, RESP0, RESP0, RESP0
    .byte   DUMMY, DUMMY, DUMMY;, DUMMY, DUMMY
Patch3Tbl
    .byte   DUMMY, DUMMY
    .byte   RESP1, RESP1, RESP1, RESP1, RESP1, RESP1
    .byte   RESP1;, RESP1, RESP1
Patch1Tbl
    .byte   RESP1, RESP1
    .byte   DUMMY, DUMMY, DUMMY, DUMMY, DUMMY, DUMMY, DUMMY, DUMMY, DUMMY

Besides that, there is special handling when only one invader of P0/1 is enabled for a row. This one is positioned outside the kernel and all RESP0/1 and the HMOVE are disabled. 

 

All kernel changes are done in the 8 scanlines between the invader rows.

 

When all invaders are the left or right columns are killed, the formation can move further left and right. This is not done by the kernel but moving the shifting the invader enabling bits. E.g. the enabling bit of the 2nd invader of a row is shifted to the position of the 1st invader. Same for all other invaders in all columns and rows. 

[Thomas Jentzsch]

6 minutes ago, Andrew Davie said:

Could the shields be PF graphics?  Do invaders/shields EVER overlap?

In the arcade they do (the invaders destroy the shields when marching over them), but in my version this is not feasible. I will either remove all shields when the invaders move down to their row (as in the current ROM) or remove the shields in two steps (top and bottom half). Whatever works better.

 

The playfield could be used for the shields. But IMO that's way to blocky, especially when the shields are getting destroyed step by step.