DPC+ Virtual Sprite Collision Testing

[+Random Terrain]

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?

[+Muddyfunster]

[RevEng]

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.

[KevKelley]

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.

[RevEng]

Right. Dpc+ collision() doesn't support NUSIZ copies or wide players.

[Lillapojkenpåön]

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?

[RevEng]

Yes, it can detect collisions when a sprite is flickered off.

[Lillapojkenpåön]

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

[RevEng]

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.

[+TwentySixHundred]

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.

[RevEng]

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.