+Random Terrain Posted March 18, 2019 Share Posted March 18, 2019 I was told that the virtual sprites are all player1, so you can't use collision() to detect collisions between them. That doesn't seem to be true: test_collision_ex_dpc_13_objects_2019y_03m_18d_1612t.bin Select player2 (the third sprite down from the top) and move it down to the last sprite (player9). Notice how the background changes color. If you move player1 over player9, the screen will not change color, so collision is seeing a difference between player1 and the virtual sprites. Here's the new code that I added to 13 Objects with Coordinates (DPC+): ;*************************************************************** ; ; New collision test. ; bkcolors: $00 end if !collision(player2,player9) then goto __Skip_Test_Hit bkcolors: $64 end __Skip_Test_Hit I put it right before this bit of code: ;*************************************************************** ; ; 22 rows that are 8 scanlines high. ; DF6FRACINC = 0 ; Background colors. DF4FRACINC = 0 ; Playfield colors. DF0FRACINC = 32 ; Column 0. DF1FRACINC = 32 ; Column 1. DF2FRACINC = 32 ; Column 2. DF3FRACINC = 32 ; Column 3. You can change the collision if-then to any of the virtual sprites and they will collide with each other perfectly. I don't know if it's always been this way or if it got changed when RevEng made some changes to batari Basic. Are there any other things that are wrong on the bB page in the DPC+ section? 2 Quote Link to comment Share on other sites More sharing options...
+Muddyfunster Posted March 18, 2019 Share Posted March 18, 2019 Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 18, 2019 Share Posted March 18, 2019 I don't know if it's always been this way or if it got changed when RevEng made some changes to batari Basic. Are there any other things that are wrong on the bB page in the DPC+ section? The collision between any of the virtual sprites was something batari added to 1.1d. Prior to that release, you couldn't check collisions between virtual sprites. 2 Quote Link to comment Share on other sites More sharing options...
KevKelley Posted March 18, 2019 Share Posted March 18, 2019 I know I had recently eliminated all the (player1,player2-9) collision statements in my program but now I am trying to figure out NUSIZ copy collisions. In that link batari mentions "doesn't support NUSIZ changes yet" so I assume while one could check collision with virtual sprites, NUSIZ copies would require collision checks still. Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 18, 2019 Share Posted March 18, 2019 Right. Dpc+ collision() doesn't support NUSIZ copies or wide players. 1 Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted March 18, 2019 Share Posted March 18, 2019 Right. Dpc+ collision() doesn't support NUSIZ copies or wide players. Do you know if it detects collisions on frames where the player in question flickers and isn't visible? Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 18, 2019 Share Posted March 18, 2019 Yes, it can detect collisions when a sprite is flickered off. 1 Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted March 19, 2019 Share Posted March 19, 2019 (edited) But not pixel perfect right? I limited my game to no flicker since the enemies (player1) and projectile you shoot (player0) moves so fast after a while that if the enemy flickered it would sometimes look and feel as if you shot right through it with no effect, since i skip the hitboxes if there's no hardware detection (to make the collision detection pixel perfect instead of square) if !collision(player0,player1) then skip ..but there isn't any hardware detection when the enemy flickers since it's somewhere else then, could this solve my problem? pixel perfect detection when the sprite is flickered? Wonder how that could work? Edited March 19, 2019 by Lillapojkenpåön Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 19, 2019 Share Posted March 19, 2019 It's pixel perfect. The DPC+ collision statement calls an ARM function, which "positions" the requested two players in some RAM while checking for overlap. The routine doesn't care if the player is flickered or not. 4 Quote Link to comment Share on other sites More sharing options...
+TwentySixHundred Posted March 20, 2019 Share Posted March 20, 2019 Yeah i was saying on Kevs bag boy thread collision detection works for virtual players with the DPC+ kernel however it still throws a warning error. I will also add, colision detection does not work between the missiles and virtual sprites though. The only way i have managed to detect the collision of virtual sprites and missiles is to set the condition as if collision(missile0,player1) then goto blahblah then using bit operations along with the x and y coords of the virtual sprite to decipher the correct virtual sprite collision. It would be nice if sometime down the track the missiles and virtual sprite collision could be added to DPC+ if possible of course. 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted March 20, 2019 Share Posted March 20, 2019 Unless batari comes back and expands the DPC+ hardware and software, it's a safe bet that we'll have no new DPC+ features. Literally it's a couple of bytes away from being too large to work. Previous updates were made by squeezing the existing code over and over, to claw back enough space to fit changes in. While bB DPC+ works well enough, the hardware acceleration idea is due for a rethink on bB. The assembly coders have mostly abandoned DPC+, and have gone straight to using ARM coding without the DPC+ interface, because the cost of all of the generic interface code is too large. I'm not sure how bB, a generic language, makes a similar change. I just know we're not at maximum horsepower. 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.