Jump to content

Multiple Sprite Shots with NUSIZ1 (Standard Kernel)


Recommended Posts

Bb Team,


I am trying to get this to work. I can get missile0 and player0 to work of course. I am trying to get NUSIZ1 = $01 (2 copies of a sprite) to work whereas one sprite is left after being shot with the missile and leaving the correct sprite. Basically if you shoot the left sprite (copy) the right sprite is left and vice versa. The next would be to move on to NUSIZ1 = $02 (3 copies of a sprite).


Currently when the sprite is hit I have the random code for player1x between 38 and 84 to help test the program. To start of with a certain amount of copies I am currently using:


; Defines numbers of sprites copies for player1
; USe "1" is there is one sprite
; Use "2" if there are two sprites
; USe "3" if there are three sprites

Sprite_Check = 2


If this works I think it can be applied to the Multisprite and DPC+ kernels. Additionally one could apply it to all the NUSIZx codes.




20180125 - Multiple_Sprite_Missile.txt


Edited by Lewis2907
Link to comment
Share on other sites

Thanks. I looked at the post. ASM is still a challenge for me, but I think I'm tracking the table to keep track of which Sprite to remove and shift left or right and adjust NUSIZx to correspond. I think it would be easier with a look up table. Then it would be based off the standard 8 by 8 Sprite. Would that be a correct assumption?

Link to comment
Share on other sites



I think the below is a following RT's Page: http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#nusiz


data ns0: $20 (2 = pixel width of missile) and (0 = sprite effect)

data pos0: Basically is the combination / location of the table to have the correct NUSIZx


If I am correct in what I am thinking on how they correspond. Did you use an excel spreadsheet or something similar to get the correct correlation? I attached a picture to illustrate what I am asking. The yellow arrow would be the other data. The double and quad would be a simple collision unless one was going to drop down to 3 sprites, etc.


***Original Data from Code***


data ns0
$20, $20, $20, $21, $20, $22, $21, $23

data pos0
$00, $20, $10, $10, $00, $00, $00, $00


Edited by Lewis2907
Link to comment
Share on other sites

I did that, like, five years ago or so and I don't remember what I did.

I'm sure I didn't use a spread sheet. It was just by inspection.

ie what needs to go where. (but by all means use a spread sheet

if it helps)

It was just something I banged together to see how it would work.

In retrospect, I was too conservative with my tables.

Looking at it now, I prefer more comprehensive table

(ie more like ZackAttack's suggestion)

So here's the new, improved version.

There will always be a sprite copy in the left position. (I have decreed it thus)

So There are only four possible configurations for the sprite.

a single sprite, a near copy, a far copy, or both copies.

(the original table is somewhat redundant in that regard)

If there is a collision it can only happen in one of three possible places

If there is a collision you may have to adjust the sprite x position and

change the configuration.

You only have to change the sprite's x position if there's a collision

with the left most sprite/copy

So you need a 3 x 4 table to look up NUSIZ0 and a table with 4 elements

for the adjustment to the x position.

(But that requires an if statement to restrict x position adjusments

to the 0 sprite position. It could be done with a twelve element table

but you'd be adjusting the sprite x position by 0 most of the time)

(the NUSIZ0 table will have four positions for situations that can't

happen, but that's about 2/3 of an if statement so well worth a little


The limit for rightward movement of the sprite will also depend on the

sprite configuration.

You could probably calculate that from the tabel for the x position adjustment,

but there's only four possibilities so its probably faster and easier

and maybe smaller to just do another table.

If there's a collision it can only happen in an interval of 40 pixels to the

right of the sprite's x position,

The copies are spaced on 16 pixel intervals so we take

(missile1x - player0x)/16

and that will give us a number 0..2 for which copy had the collision.

I use that as the row address and since there's four values per row

its divide by 16 multiply by 4 ie divide by 4 with an AND mask to get rid

of the fractional part.

((missile1x - player0x)/16) & %00001100

I save the sprite configuration in bits 0..1 of jf and changed missile fired

flag to jf{7} (0 if the missile's fired) (there's also a direction flag, jf{6})

So the table address for the new sprite configuration is

(((missile1x - player0x)/16) & %00001100) | (jf & %00000011)

The playfield junk in the lower right is jf with some pixels below it to

indicate the bit positions (var40 = $55, var36 = jf)

edit: I swapped missile1x and player0x above (not in the code) (now fixed)

I left out the bit reference in the if predicate so you can (re)fire the missile

some times when you shouldn't be able to

line 69 in the code should be

if joy0fire && jf{7} then missile1x = player1x + 3 : missile1y = 80 : jf{7} = 0



Edited by bogax
  • Like 1
Link to comment
Share on other sites

Thanks to Bogax code. I was able to make some modifications. I have updated it to the Multisprite Kernel. You can now move around the screen and shot the enemy from any direction. I added some notes in the program to explain what I did. I will make the same modifications for the Standard Kernel. I may do a DPC version as well. The issues that I have for DPC and Multisprite are collision player2 and up.




Below is a code that could be adpated from RT's site to have collsion, but it won't work properly for player2 on up.


; Checks for player0 collision with other 9 sprites.
; 10 is used for the y check because these sprites are 11
; pixels high (11 - 1 = 10). For example, if your sprite is
; 40 pixels tall, use 39 instead of 10.
if !collision(player0,player1) then goto __Skip_p0_Collision
temp5 = _Data_Sprite_Width[_Sprite_Size0]
if (player0y + 10) >= player1y && player0y <= (player1y + 10) && (player0x + temp5) >= player1x && player0x <= (player1x + 7) then pfpixel 9 11 on
if (player0y + 10) >= player2y && player0y <= (player2y + 10) && (player0x + temp5) >= player2x && player0x <= (player2x + 7) then pfpixel 9 20 on
if (player0y + 10) >= player3y && player0y <= (player3y + 10) && (player0x + temp5) >= player3x && player0x <= (player3x + 7) then pfpixel 9 28 on
if (player0y + 10) >= player4y && player0y <= (player4y + 10) && (player0x + temp5) >= player4x && player0x <= (player4x + 7) then pfpixel 9 37 on
if (player0y + 10) >= player5y && player0y <= (player5y + 10) && (player0x + temp5) >= player5x && player0x <= (player5x + 7) then pfpixel 9 46 on
if (player0y + 10) >= player6y && player0y <= (player6y + 10) && (player0x + temp5) >= player6x && player0x <= (player6x + 7) then pfpixel 9 55 on
if (player0y + 10) >= player7y && player0y <= (player7y + 10) && (player0x + temp5) >= player7x && player0x <= (player7x + 7) then pfpixel 9 63 on
if (player0y + 10) >= player8y && player0y <= (player8y + 10) && (player0x + temp5) >= player8x && player0x <= (player8x + 7) then pfpixel 9 72 on
if (player0y + 10) >= player9y && player0y <= (player9y + 10) && (player0x + temp5) >= player9x && player0x <= (player9x + 7) then pfpixel 9 81 on






I think the below can be adjusted, but not sure how for player2 on up.


; colidx, collision index, which copy did we hit
colidx = ((ballx - player0x)/4 & $0C) | cscon : bally = 0

if !cscon then jf = $83 : p0x = 56 : p0v = 0.25 : goto no_collision

jf = (jf & $40) | scon[colidx]

; if position 0
if colidx < 4 then player0x = player0x + pos0[cscon]






Below is how to change the NUSIZx to what ever you want it to be. I also used ball as missile will duplicate to what ever player2 on up is for NUSIZx.


; change (jf & $03) | $06 to $0x and $m below to have correct NUSIZx
; example (jf & $06) | $03 is 3 close-spaced copies of player and missile.
; example (jf & $00) | $07 is Quad-sized player.
; RT Page will help select the code:
; http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#nusiz
; m = 0 1 pixel wide missile.
; m = 1 2 pixel wide missile.
; m = 2 4 pixel wide missile.
; m = 3 8 pixel wide missile.
; x = 0 1 copy of player and missile.
; x = 1 2 close-spaced copies of player and missile.
; x = 2 2 medium-spaced copies of player and missile.
; x = 3 3 close-spaced copies of player and missile.
; x = 4 2 wide-spaced copies of player and missile.
; x = 5 Double-sized player.
; x = 6 3 medium-spaced copies of player and missile.
; x = 7 Quad-sized player.
NUSIZ0 = (jf & $00) | $07
NUSIZ1 = $10






Attached is the Standard Kernel Version, thanks.


Attached is the DPC Version, thanks.


20180203 - (Multisprite)_Multiple_Sprite_Shot.txt



20180203 - (Standard)_Multiple_Sprite_Shot.txt


20180203 - (DPC)_Multiple_Sprite_Shot.txt

Edited by Lewis2907
Link to comment
Share on other sites



Thanks. Kinda reminds me of Space Invaders. I see that you have it in the Standard Kernel. I will try to port this over to Multisprite / DPC+. Hopefully is will work. If so I can use this in the game i'm making called "The Quest". Thanks again for the code.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...