+Lewis2907 Posted January 26, 2018 Share Posted January 26, 2018 (edited) 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. Multiple_Sprite_Missile.bas.bin 20180125 - Multiple_Sprite_Missile.txt Edited January 26, 2018 by Lewis2907 Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 26, 2018 Share Posted January 26, 2018 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? Quote Link to comment Share on other sites More sharing options...
+Lewis2907 Posted January 26, 2018 Author Share Posted January 26, 2018 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? Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 26, 2018 Share Posted January 26, 2018 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. Quote Link to comment Share on other sites More sharing options...
bogax Posted January 27, 2018 Share Posted January 27, 2018 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) Quote Link to comment Share on other sites More sharing options...
+Lewis2907 Posted January 27, 2018 Author Share Posted January 27, 2018 Bogax, That is exactly it. I will adjust the program around to incorporate the NUSIZx, thanks. Multiple_Sprite_Missile_v1.bas.bin 20180126 - Multiple_Sprite_Missilev1.txt Quote Link to comment Share on other sites More sharing options...
+Lewis2907 Posted January 28, 2018 Author Share Posted January 28, 2018 (edited) Bogax, 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, $23end data pos0 $00, $20, $10, $10, $00, $00, $00, $00 end Edited January 28, 2018 by Lewis2907 Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 28, 2018 Share Posted January 28, 2018 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. Quote Link to comment Share on other sites More sharing options...
bogax Posted January 28, 2018 Share Posted January 28, 2018 (edited) 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 x3_2.bas x3_2.bas.bin Edited January 28, 2018 by bogax 1 Quote Link to comment Share on other sites More sharing options...
+Lewis2907 Posted February 3, 2018 Author Share Posted February 3, 2018 (edited) 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.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 *****Edit***** Attached is the Standard Kernel Version, thanks. Attached is the DPC Version, thanks. 20180203 - (Multisprite)_Multiple_Sprite_Shot.txt Multisprite_Sprite_Missile_v2.bas.bin Standard_Kernel_Sprite_Missile.bas.bin 20180203 - (Standard)_Multiple_Sprite_Shot.txt DPC_Kernel_Sprite_Missile.bas.bin 20180203 - (DPC)_Multiple_Sprite_Shot.txt Edited February 3, 2018 by Lewis2907 Quote Link to comment Share on other sites More sharing options...
bogax Posted February 9, 2018 Share Posted February 9, 2018 (edited) just playin' x6_1.bas x6_1.bas.bin Edited February 9, 2018 by bogax 1 Quote Link to comment Share on other sites More sharing options...
+Lewis2907 Posted February 9, 2018 Author Share Posted February 9, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.