Jump to content

Photo

Multiple Sprite Shots with NUSIZ1 (Standard Kernel)


11 replies to this topic

#1 Lewis2907 ONLINE  

Lewis2907

    Chopper Commander

  • 206 posts
  • Location:Senatobia, MS

Posted Thu Jan 25, 2018 8:46 PM

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.

 

 

Attached Thumbnails

  • NUSIZx.png

Attached Files


Edited by Lewis2907, Thu Jan 25, 2018 8:57 PM.


#2 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • 648 posts
  • Location:Orlando, FL US

Posted Thu Jan 25, 2018 9:36 PM

We were actually just discussing this in the assembly forum. I proposed an algorithm which could be used in bB too. Maybe that helps you?



#3 Lewis2907 ONLINE  

Lewis2907

    Chopper Commander

  • Topic Starter
  • 206 posts
  • Location:Senatobia, MS

Posted Thu Jan 25, 2018 10:16 PM

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?

#4 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • 648 posts
  • Location:Orlando, FL US

Posted Thu Jan 25, 2018 10:26 PM

Sprite height shouldn't matter. Since multiple copies are involved you'll be forced to use single wide sprites. The table will need to be specific to which spacing you start with. 3 close and 3 medium would be different tables.



#5 bogax OFFLINE  

bogax

    Dragonstomper

  • 758 posts

Posted Fri Jan 26, 2018 7:49 PM



We were actually just discussing this in the assembly forum. I proposed an algorithm which could be used in bB too. Maybe that helps you?

 

not sure I'm following you

 

but it sounds like this (sort of, this has two tables, not one) 



#6 Lewis2907 ONLINE  

Lewis2907

    Chopper Commander

  • Topic Starter
  • 206 posts
  • Location:Senatobia, MS

Posted Fri Jan 26, 2018 8:16 PM

Bogax,

 

That is exactly it. I will adjust the program around to incorporate the NUSIZx, thanks. 

Attached Files



#7 Lewis2907 ONLINE  

Lewis2907

    Chopper Commander

  • Topic Starter
  • 206 posts
  • Location:Senatobia, MS

Posted Sat Jan 27, 2018 10:50 PM

Bogax,

 

I think the below is a following RT's Page: http://www.randomter...ands.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
end

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

Attached Thumbnails

  • NUSIZ.png

Edited by Lewis2907, Sat Jan 27, 2018 10:51 PM.


#8 ZackAttack OFFLINE  

ZackAttack

    Dragonstomper

  • 648 posts
  • Location:Orlando, FL US

Posted Sat Jan 27, 2018 10:56 PM

 

not sure I'm following you

 

but it sounds like this (sort of, this has two tables, not one) 

 

Yeah, that's pretty much what I had in mind.



#9 bogax OFFLINE  

bogax

    Dragonstomper

  • 758 posts

Posted Sun Jan 28, 2018 11:10 AM

 
 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
 redundancy)
 
 
 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
       

Attached Files


Edited by bogax, Sun Jan 28, 2018 3:53 PM.


#10 Lewis2907 ONLINE  

Lewis2907

    Chopper Commander

  • Topic Starter
  • 206 posts
  • Location:Senatobia, MS

Posted Sat Feb 3, 2018 3:55 PM

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

__Skip_p0_Collision

 

 

 

 

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]

no_collision

 

 

 

 

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.randomter...ands.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

 

 

 

*****Edit*****

 

Attached is the Standard Kernel Version, thanks. 

 

Attached is the DPC Version, thanks. 

 

Attached Files


Edited by Lewis2907, Sat Feb 3, 2018 4:51 PM.


#11 bogax OFFLINE  

bogax

    Dragonstomper

  • 758 posts

Posted Fri Feb 9, 2018 10:13 AM

just playin'

 

 

Attached Files


Edited by bogax, Fri Feb 9, 2018 11:25 AM.


#12 Lewis2907 ONLINE  

Lewis2907

    Chopper Commander

  • Topic Starter
  • 206 posts
  • Location:Senatobia, MS

Posted Fri Feb 9, 2018 11:44 AM

Bogax,

 

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. 






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users