Jump to content

Photo

DPC+ Virtual Sprite Collision Testing


10 replies to this topic

#1 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,982 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Mon Mar 18, 2019 2:33 PM

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:
 
Attached File  test_collision_ex_dpc_13_objects_2019y_03m_18d_1612t.bin   32KB   16 downloads
 
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 Muddyfunster OFFLINE  

Muddyfunster

    Moonsweeper

  • 312 posts

Posted Mon Mar 18, 2019 2:37 PM

:-o



#3 RevEng OFFLINE  

RevEng

    Bit Player

  • 5,192 posts
  • Location:bottom of the stack

Posted Mon Mar 18, 2019 3:27 PM

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.

#4 KevKelley OFFLINE  

KevKelley

    Chopper Commander

  • 213 posts
  • Lots of hobbies, little time, loads of fun.
  • Location:Orlando

Posted Mon Mar 18, 2019 3:47 PM

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.

#5 RevEng OFFLINE  

RevEng

    Bit Player

  • 5,192 posts
  • Location:bottom of the stack

Posted Mon Mar 18, 2019 4:22 PM

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

#6 Lillapojkenpćön OFFLINE  

Lillapojkenpćön

    Chopper Commander

  • 195 posts

Posted Mon Mar 18, 2019 5:27 PM

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?



#7 RevEng OFFLINE  

RevEng

    Bit Player

  • 5,192 posts
  • Location:bottom of the stack

Posted Mon Mar 18, 2019 5:32 PM

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

#8 Lillapojkenpćön OFFLINE  

Lillapojkenpćön

    Chopper Commander

  • 195 posts

Posted Mon Mar 18, 2019 7:23 PM

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 by Lillapojkenpćön, Mon Mar 18, 2019 7:45 PM.


#9 RevEng OFFLINE  

RevEng

    Bit Player

  • 5,192 posts
  • Location:bottom of the stack

Posted Mon Mar 18, 2019 8:00 PM

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.

#10 TwentySixHundred OFFLINE  

TwentySixHundred

    Moonsweeper

  • 453 posts
  • 1.19 MHz
  • Location:Adelaide, Australia

Posted Wed Mar 20, 2019 6:55 AM

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.



#11 RevEng OFFLINE  

RevEng

    Bit Player

  • 5,192 posts
  • Location:bottom of the stack

Posted Wed Mar 20, 2019 7:20 AM

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.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users