PacManPlus
-
Content Count
5,644 -
Joined
-
Days Won
28
Blog Comments posted by PacManPlus
-
-
Hi:
Thanks guys!
Just got back from Mohegan Sun (I didn't win)
. I actually worked on this while I was there I think I have it to where the player's shot explosion removes itself from the shield (see first post for bin). The only thing, is that I'll have to use this subroutine up to a maximum of 4 times (if dual players, one for each player's shot and one for each invader's shot). I don't think there will be enough CPU time to do all of that. Is there a way to reduce this subroutine?
The Characters at D0/D1, D2/D3, D4/D5, and D6/D7 have the inverted explosion graphics at different positions within the shot's byte position. The D0/D1 and D2/D3 need the shield RAM byte to be subtracted by 1 because the graphics bleed into the previous byte.
One thing that bothers me, though, is that certain shield locations cannot be hit. The shot passes right through them. I guess that's because the y position of the shot gets 3 added to it each frame, so it can 'miss' an area of the shield if it's between those values.
;******** remove piece of shield that player shot hit ;******** inputs: temp - y position of shot, temp2 - x position of shot ;******** uses: a, x, y, temp, temp2, tmpadrl, tmpadrh ChipShieldPlayer_Rts2 rts ChipShieldPlayer lda temp;get y value of shot to shot eor #144;Exclusive OR it with #$90 (the beginning 'y' of the shield) cmp #16 ;Carry will be clear if shot position is in range bcs ChipShieldPlayer_Rts2 sta shieldrow tax lda Shield2ShotL,x sta tmpadrl lda Shield2ShotH,x sta tmpadrh lda temp2;get x value of shot sec sbc #leftside;shift origin sta shieldcol;store it tax lsr lsr ;divide by 4 (pixel definition may be 8, but pos is 4) sta shieldbyte;this is the byte offset where the shot hit the shields tay lda (tmpadrl),y and Shot2Bit,x;did the shot hit a section of the shield? beq ChipShieldPlayer_Rts2;no, exit ChipShieldPlayer_SetUp lda #$00 sta shieldidx;we will need to remove 8 rows of pixels lda shieldrow;get the current collision row sec sbc #$03;we need to go 3 pixels higher that where the shot hit sta shieldrow ChipShieldPlayer_Loop lda shieldrow;get the current shield row (of 16) bmi ChipShieldPlayer_Next;if it's not in range (0-15) skip tax lda Shield2ShotL,x;get the start of ram for this row sta tmpadrl lda Shield2ShotH,x sta tmpadrh lda shieldidx;get the current explosion row (of 8) clc adc #>fontdata;find the pointer to the graphic data sta tmprowh lda #$00 sta tmprowl ldy shieldcol lda Clear2Bit,y tay lda (tmprowl),y;get the current explosion byte definition (1st byte) sta shieldand1 iny lda (tmprowl),y;get the current explosion byte definition (2nd byte) sta shieldand2 ldy shieldcol;do we have to subtract 1 from the byte column? lda Shot2Offset,y clc adc shieldbyte tay lda (tmpadrl),y;and get the current ram location of the shot shield and shieldand1 sta (tmpadrl),y;'AND' them together and put the value back iny lda (tmpadrl),y and shieldand2 sta (tmpadrl),y ChipShieldPlayer_Next inc shieldrow lda shieldrow cmp #$16 bpl ChipShieldPlayer_Rts inc shieldidx lda shieldidx cmp #$08 bpl ChipShieldPlayer_Rts bmi ChipShieldPlayer_Loop ChipShieldPlayer_Rts jmp RemoveP1Shot;remove the player's shot Shot2Bit .byte $c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03 .byte $c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03 .byte $c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03 .byte $c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03 .byte $c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03 .byte $c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03 .byte $c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03 Shot2Offset .byte $ff,$ff,$00,$00,$ff,$ff,$00,$00,$ff,$ff,$00,$00,$ff,$ff,$00,$00 .byte $ff,$ff,$00,$00,$ff,$ff,$00,$00,$ff,$ff,$00,$00,$ff,$ff,$00,$00 .byte $ff,$ff,$00,$00,$ff,$ff,$00,$00,$ff,$ff,$00,$00,$ff,$ff,$00,$00 .byte $ff,$ff,$00,$00,$ff,$ff,$00,$00,$ff,$ff,$00,$00,$ff,$ff,$00,$00 .byte $ff,$ff,$00,$00,$ff,$ff,$00,$00,$ff,$ff,$00,$00,$ff,$ff,$00,$00 .byte $ff,$ff,$00,$00,$ff,$ff,$00,$00,$ff,$ff,$00,$00,$ff,$ff,$00,$00 .byte $ff,$ff,$00,$00,$ff,$ff,$00,$00,$ff,$ff,$00,$00,$ff,$ff,$00,$00 Clear2Bit .byte $d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6 .byte $d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6 .byte $d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6 .byte $d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6 .byte $d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6 .byte $d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6 .byte $d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6,$d0,$d2,$d4,$d6 Shield2ShotL .byte <(shields+$700),<(shields+$600),<(shields+$500),<(shields+$400) .byte <(shields+$300),<(shields+$200),<(shields+$100),<(shields+$000) .byte <(shields+$720),<(shields+$620),<(shields+$520),<(shields+$420) .byte <(shields+$320),<(shields+$220),<(shields+$120),<(shields+$020) Shield2ShotH .byte >(shields+$700),>(shields+$600),>(shields+$500),>(shields+$400) .byte >(shields+$300),>(shields+$200),>(shields+$100),>(shields+$000) .byte >(shields+$720),>(shields+$620),>(shields+$520),>(shields+$420) .byte >(shields+$320),>(shields+$220),>(shields+$120),>(shields+$020)
Also, I give point values for shooting the ufo now. (see first post)
*NOTE*, please ignore that shooting the shield sometimes gives you points, I know what that is, and I will fix it.
Bob
-
Thanks
Even though I'm only using 28, I'm leaving space for 32 (there are four extra bytes at the end of each pixel row that I'm not copying). I had a feeling it would be easier on a $20 byte boundary
ok, I'm back to work
-
Was it only enemy shots that exploded bits off the shield, while the player shots just chipped away at it? It's been ages since I've played that game.Actually both exploded bits off the shield, although the player's shots have a different explosion bitmap than the invaders do.
I am looking at incorporating your changes to the x & y coordinate mapping now. Although I may extend the shield section of the bitmap to all 28 horizontal character positions (the playfield is 28 characters wide), and just check the exact location of the shot in the bitmap field. I thought this may be a good idea in case I wanted to offer different shield shapes (like Gorf, that shapes the shield like an arc and extends the entire length of the screen)... Good idea?
-
Hey Supercat:
Before I read your blog comment here (while this site was down) I made a little progress in this department. I intend to read and attempt to fully understand what you are doing in the above code (because I would bet a year's salary that it's *much* more efficient that what I've done). But, I just wanted to show what I was able ot figure out:
;******** remove piece of shield that shot hit ;******** inputs: temp - y position of shot, temp2 - x position of shot ;******** uses: a, x, y, temp, temp2, tmpadrl, tmpadrh ChipShield lda temp ;get y value of shot to shield cmp #$90 ;#$90 is the y-coordinate of the top of the shield bcc ChipShieldRts;if the shot is higher than the shield, exit sec sbc #$90 ;shift origin to the beginning (#$00) cmp #$10 ;#$10 (16 decimal) is now the bottom of the shield - two rows of 8 bpl ChipShieldRts;if the shot is still lower than the shield, exit tax lda Shield2ShotL,x;this gets the beginning address of the bitmap definition for each pixel line sta tmpadrl lda Shield2ShotH,x sta tmpadrh lda temp2 ;get x value of shot to shield sec sbc #$25 ;shift origin bmi ChipShieldRts;if the shot is to the left of the left-most shield, exit tax lsr ;each line of bitmap is 21 bytes - we need to figure the offset here lsr ;divide by 4 (pixels per character may be 8, but position is 4) tay ;this is the byte offset where the shot hit the shields lda (tmpadrl),y;load the byte at the position the shot hit and Shot2Bit,x;'AND' it with the 'fine' position of the shot (shot bitmap is $80) beq ChipShieldRts;if it's already erased (from a previous shot), exit lda (tmpadrl),y;re-load the value (to be erased) and Clear2Bit,x;remove the part the shot hit sta (tmpadrl),y;store it back jsr RemoveP1Shot;remove the player's shot ChipShieldRts rts Shot2Bit .byte $c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03 .byte $c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03 .byte $c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03 .byte $c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03 .byte $c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03 .byte $c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03 .byte $c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03,$c0,$30,$0c,$03 Clear2Bit .byte $3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc .byte $3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc .byte $3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc .byte $3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc .byte $3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc .byte $3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc .byte $3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc,$3f,$cf,$f3,$fc Shield2ShotL .byte <(shields+$700),<(shields+$600),<(shields+$500),<(shields+$400) .byte <(shields+$300),<(shields+$200),<(shields+$100),<(shields+$000) .byte <(shields+$720),<(shields+$620),<(shields+$520),<(shields+$420) .byte <(shields+$320),<(shields+$220),<(shields+$120),<(shields+$020) Shield2ShotH .byte >(shields+$700),>(shields+$600),>(shields+$500),>(shields+$400) .byte >(shields+$300),>(shields+$200),>(shields+$100),>(shields+$000) .byte >(shields+$720),>(shields+$620),>(shields+$520),>(shields+$420) .byte >(shields+$320),>(shields+$220),>(shields+$120),>(shields+$020)
Keep in mind, this is very early; I plan to XOR the actual shot sprite like the arcade does - after going over your code (which I thank you for, BTW)
So... how bad is my code?
I actually repeat this subroutine 3 times (because the shot moves in increments of 3 pixels, and I have to clear the two pixels under where the shot hit).I have included the bin in the first post. The following changes are there:
1) Changed colors to be more 'compatable' with TVs
2) Added preliminary collision detection for the UFO - no points awarded, it just turns into an explosion graphic and keeps going.
3) Added Shields, and preliminary shot detection on the shield
4) THE INVADERS NOW REACH THE SIDE OF THE SCREEN CORRECTLY!!!
5) When shot, the invaders temporarily turn into an explosion graphic, and pause (like the arcade).
6) If an invader reaches the bottom of the screen, the game ends (endless loop for now)
7) The invaders drop one line after each rack. No boundary checking yet, so the game eventually becomes unplayable because they are too low.
BTW, does anyone have the point value list table of the UFO for each player shot?
Thanks!
Bob
-
Hey Supercat - it's funny; any time I feel like I'm starting to understand more of the 7800, all I have to do is look at your code and I feel stupid again
Before I do anything I will continue to read it until I understand completely what's going on...
So I'm guessing what I was planning to do with the shields won't work? (keep the bitmap itself in RAM and once the 'Y' value of a shot is in the range of the shields, subtract the 'X' value of that shot from the shield sprite for each of the 16 scanlines and remove if that section exists).
Also, there is another issue that I just found. In the arcade version, when a shot ends or hits a shield, there is a small explosion graphic that gets shown for about 1/4 of a second. That graphic is then XOR'ed with the section of the shield it hit to remove it. This goes through more that one scanline at a time, which will make things quite difficult (for me).
hmmm....
-
Hey Bob:
The labels I am using refer to the memory locations I am storing the DL, DLL, and Character Memory. I went just over the first section of usable RAM (to $2840 instead of $27FF).
The 'Screen RAM' I am referring to is the RAM for each line of the screen in character mode. There are 28 ($1C) bytes per line (I rounded it out to $20 becuase it was easier to work with) that denote the characters on the line (It's what gets manipulated for the invaders to march), as well as the score line and the status line at the bottom. (Character Memory) I hope I explained that correctly...
I am using one long sprite instead of 4 separate ones because: It makes it easier to check if there is a collision; checking if a pixel is on for one long sprite instead of 4 separate sprites in different places (at least to me it does). I have to check each of the up to 16 vertical pixels of the shields to find one that is on at the x position of the player's (or invader's) shot, and remove it if it is. Also, the other reason is there are 6 fewer DL entries, 30 less bytes to process (and to take up RAM).
I am using sprites (not Character Mode) for the shields. I think I *have* to use character mode - the spaces between the shields is not an even '24', and I have to chip away bits of the shield from each shot - I can't do that with character mode, can I?
By all means if I am going about this the wrong way, please let me know. As (I'm sure) you can tell, my knowledge is very limited here.
Thanks, Bob & Supercat
Bob
-
I got it:
I was able to squeeze another $100 bytes out of the Display List List, so I could then move it to the $2200 area. The Screen RAM still immediately followes it:
;******** display list ram
dllist = $2200 ; $300 bytes for DLL & DL
charmem = $2500 ; begin screen ram
lhead = charmem+$00
lscore = charmem+$20
l00 = charmem+$40
l01 = charmem+$60
l02 = charmem+$80
l03 = charmem+$a0
l04 = charmem+$c0
l05 = charmem+$e0
l06 = charmem+$100
l07 = charmem+$120
l08 = charmem+$140
l09 = charmem+$160
l10 = charmem+$180
l11 = charmem+$1a0
l12 = charmem+$1c0
l13 = charmem+$1e0
l14 = charmem+$200
l15 = charmem+$220
l16 = charmem+$240
l17 = charmem+$260
l18 = charmem+$280
l19 = charmem+$2a0
l20 = charmem+$2c0
l21 = charmem+$2e0
l22 = charmem+$300
lstat = charmem+$320
So now I have $1800-$203F free for the shields.
Now I just need to figure out how to make them deteriorate with each shot that hits them.*EDIT* - Actually it looks like I have to find another $40 bytes - the screen RAM extends to $283F... Into the shadow area. I'll fix it
-
Thanks, Supercat - I'm going to need to read this over a few times before I follow what's going on here...
BTW, I alse moved the Screen RAM to be just under the DLL & DL, so it looks like this now:
;******** display list ram
dllist = $1800 ; $400 bytes for DLL & DL
charmem = $1c00 ; begin screen ram
lhead = charmem+$00
lscore = charmem+$20
l00 = charmem+$40
l01 = charmem+$60
l02 = charmem+$80
l03 = charmem+$a0
l04 = charmem+$c0
l05 = charmem+$e0
l06 = charmem+$100
l07 = charmem+$120
l08 = charmem+$140
l09 = charmem+$160
l10 = charmem+$180
l11 = charmem+$1a0
l12 = charmem+$1c0
l13 = charmem+$1e0
l14 = charmem+$200
l15 = charmem+$220
l16 = charmem+$240
l17 = charmem+$260
l18 = charmem+$280
l19 = charmem+$2a0
l20 = charmem+$2c0
l21 = charmem+$2e0
l22 = charmem+$300
lstat = charmem+$320
;$1f40 - $203f free
This leaves me with $2200-$27FF free (still not enough, but at least it contiguous)
-
Thanks Bob, for the stats. I had to take away 4 lines to fit on the standard screen (I had 208 lines to work with). I removed one line of text, and 3 lines of playfield.
...
This sucks.
I don't have 8 contiguous pages of memory free for the shields. I originally was doing the shields as 4 individual ones, when I realized I could save a few Display List entries by doing one long shield, only filled in where the 4 of them are supposed to be. But, I need to put them in RAM, so I need 8 pages (each line is on a different page). I'm even using zero-page RAM for all of my game variables so far. Here's my RAM:
;******** display list ram
dllist = $1800 ; $400 bytes
;$1c00 - $203f left
;******** screen ram
charmem = $2200
lhead = $2200
lscore = $2220
l00 = $2240
l01 = $2260
l02 = $2280
l03 = $22a0
l04 = $22c0
l05 = $22e0
l06 = $2300
l07 = $2320
l08 = $2340
l09 = $2360
l10 = $2380
l11 = $23a0
l12 = $23c0
l13 = $23e0
l14 = $2400
l15 = $2420
l16 = $2440
l17 = $2460
l18 = $2480
l19 = $24a0
l20 = $24c0
l21 = $24e0
l22 = $2500
lstat = $2520
;$2540 - $27ff left
I've been trying to move things around, but no matter what I won't have enough free.
-
Hi!
The Invaders are two characters wide, right next to each other (which reminds me of something else; I have to do the fine-tuning collision detection between the shot and the invaders... right now you can't shoot in between them).
hmmm...
-
Thanks, Bob
Hmmm... ok you gave me something to think about. The code you have there I will have to use for all 5 rows and keep the outermost position for all 5. I'll give it a shot - thanks!
PS, you've got PM
-
@Supercat - Thanks for trying to explain, but as I say below I am just now finally understanding the 7800 Display List basics. You guys seem to be *extremely* knowledgable about the 2600, 7800, etc. I wish I was at that level.
@Bob - Talk about losing someone in the specifics!
Please keep in mind I am just now finally understanding the basics of the 7800 Display List (List). BTW, I am using 8 line zones. All of the characters in SI are 8 pixels high (except the shields, and I just put them in two zones). Also, you are correct; SI is 224 pixels wide.But there is another timing issue to worry about... All of this stuff has to happen and still be fast enough that the last invader zooms accross the screen! ...Which brings me to my next point: I took out the 'wave' of the invaders marching. They all move at once again. It was just too much, trying to keep track of which line to move at which frame... Keeping track of the current DLL and Screen Ram Line as to only move those 5 rows. The last invader didn't move very fast at all. So, I reverted back to how it was originally created.
BTW, can you have two character mode display lists in the same zone? If so, that could be a good way to do the background as well. (If that's what you meant, I apologize)
...
Collapsing Zones?
...
Bob
P.S. Another thing I noticed, is that I have to figure out how to tell when a whole outside column has been destroyed and allow the rest of the invaders to move that much farther toward the edge of the screen when marching... hmmm....
...Also, why does the color Red look so damn horrible in 320 mode? I tried it on two different TVs just to make sure it wasn't the TV and it looks the same. The UFO looks like it was already shot - a few times. You can barely make out the shape of the top row of invaders as well (I guess the 'red' part in the purple is doing it)
I may make everything white, like the arcade. Updated Binary in first post - Scoring was added, the shield sprites were added (although they don't do anything), and rack refresh was added.
-
...as there would be too many sprites (55 invaders + 4 shields + 3 shots + player + ufo) for each line of the display list.
Why do you include all those things in your total? Eleven invaders, two shots, and the four shields would be the max I could see.
If I were doing this with sprites, it's a possibility (as you get toward the bottom of the screen) that all of those things can occupy a particular zone. They don't have to all be there at the same time, but the provision has to be made for all of them... except the player, I guess, which would only be on the bottom row. At least that's how I understand the display list entry; if a sprite can occupy the zone a display list describes, it must be included in that display list.
Am I understanding that correctly?
-
Sorry guys, I haven't been on much lately and I didn't see this until today.
@Walter - Thanks
I have actually started from scratch again because what I was doing was not the correct way of handeling the invaders. I am still working on it!@Bob - I am using 320A, and I will use RAM for the shields (thanks for that). I'm just curious on how to chip away the exact section of the shield that the shots hit, being that there is no hardware collision detection on the 7800! :-/ As far as the background, I actually thought of trying to replicate the 'moon' scenario, but I have to use the character set for the invaders, as there would be too many sprites (55 invaders + 4 shields + 3 shots + player + ufo) for each line of the display list.
Thanks!
Bob
-
Now.....
I think I have the 'ripple' matched like the arcade does. The only thing that bothers me, is that at their fastest march (when there's only one left), they aren't as fast as the arcade game.
It's probably because of the way I coded this; I have a feeling the code is sort of 'bloated' because I am not that versed with the tricks used to streamline assembler code. I have included my latest attempt in the first post (for some reason I can't add attachments to this post). They only move one speed, there is no collision detection with the UFO, the invaders don't shoot back, and there still are no shields. They also don't stop once they reach the ground.
I need to streamline the missile / invader collision too.
-
I actually was thinking a Sprite for the shields as well. I was more thinking of how to do the 'break-away' part when the bomb (or player's shot) hits it...
I know what you guys are talking about with regard to he 'ripple effect'. That was bugging me because it was always in the back of my mind that I had to do that. Now that you brought it out into the open (
) I have to figure it out. I'd like to change he invaders to sprites. Do you think manipulating 55 sprites (+player +ufo +4 shields) per frame will be too much for Maria? That said, it's kind of on hold for now. I'll have to get back to it again
-
Thanks, guys
I'll pick it up again at some point (I hope). -
Very, VERY cool.
I love the eyes on the title screen and how they blink at you as well.
The animation sequence when the Wumpus devours you is much more scary than the TI version - I wasn't expecting it.
I'm guessing the green bars are the Swamp Pits, and the red bars are the Wumpus blood clues.
I noticed that you play the 'Wumpus catches you' animation when you seem to fall into a pit. Is this a placeholder until you have the pit animation done?
I love how this is coming out. - Great work
Bob
-
You know, I can see this *very* easily turning into a port of the 'Advanced D&D: Cloudy Mountain' game... That was my favorite game on the Intellivision, and I've always wanted to see if the 2600 could pull that off...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Some progress on Space Invaders 7800
in PacManPlus' Blog
A blog by PacManPlus
Posted
Yes, That has to do with when you get 'points' for shooting the shields. The player's shot has already been removed, but it's still checking for collisions with the invaders. I will fix that in the next attachment. I am going to separate the collision checks into a separate subroutine, and exit once a collision has been detected.
I'm hoping that the above routine can be condensed somewhat. I also PM'ed opcode to ask if he has the 'UFO point value' table, indexed by player's shot.
BTW, Allan, hope all is well. I think in a few months I will be having another 'Classic Gaming Night'.