pfpixel Collision Detection

[KevKelley]

I had originally mentioned this issue in the Moving pfpixels thread but since that post was focused more on moving the pfpixels and this issue dealt more with the collision detection of them, I made this separate post.

 

I seem to be at an impasse with trying to figure out how to get these pfpixels to dissappear!

 

I followed the forums and code examples from RT's site and for the most part I got the code to work... except when it wouldn't.  As I posted in the other thread, the goal was to hit a pfpixel, turn it off, and immediately replace it with a ball so that the player1 can move around with the ball giving it a smoother movement.  When the ball hits the missile1 it disappears and player1 must go grab another pfpixel.

 

The only pfpixels that would be allowed to be affected are the smaller ones on the bottom left half of the screen (I use pfheights).  The issue I seem to be experiencing is that they would inconsistently disappear. Sometimes a ball would appear.  Sometimes it wouldn't. Sometimes the pfpixel would disappear.  I rewrote the code in various ways to see if I can tweak it to get it to work.  Some iterations would work better than others.  Sometimes things would go haywire and random playfield pixels would dissappear.  I thought maybe it was an issue with where the collision detection appeared in the code so moved it around a bit or that I was using temp variables so I changed that too but to no avail. I tried the suggestions mentioned but can't seem to wrap my head around this.  Was curious if anyone had any ideas where I went wrong with this issue!

 

Here are a couple of the files I had worked with to see if I could get different results.

 

 

CD_03_18_2020.bas CD_03_15_2020.bas

[Sknarp]

Not sure if this is the exact issue you have, but you are updating the player's position both before and after the drawscreen from the same joystick input, that might be throwing off your colisions. Also on the first one I don't think the Bitop_Joy_Direction is ever dim'd

[KevKelley]

I had moved the drawscreen in a different spot to check on if that was the reason but it didn't work and came with its own problems, namely the player1 sticking to the playfield.

 

I had never really used that method of movement before so I had considered changing that whole segment (I had copied that from an example program and thought it seemed straightforward and simple. I had considered that might be an issue though. I had thought that the collision check in the movement was interfering with the collision of the playfield blocks which is why I tried to make a bounding box for the affected pfpixels. I may not have implemented it correctly though but I'll go through it later today and check.

 

Thanks for the tips. 

[Lillapojkenpåön]

The problems are that you are using pfheights, different sized pfpixels.

And also only one pfpixel conversion: e=((player1x - 16) / 4) :f=(player1y - 8) / 8

 

You need to do alot more conversions, especially if you want to get rid of the sticky collision detection 

and use collision prevention.

 

In the most important area your pfpixel height is four, that's the resolution of a 22 row playfield so divide by four instead

but you also have to account for the very long pfpixel, so it should be something like this instead

e=((player1x - 16) / 4) :f=(player1y - 8 - 34) / 4

 

This is far from perfect but works well,

you can throw away the box with fire button.

 

 

 

collision_prevention_6.bas

Edited March 20, 2020 by Lillapojkenpåön

[KevKelley]

Ah! I didn't think about the difference of pixel heights! I guess that would explain why seemingly random pixels would turn off?

 

So if I understand this, the conversion for the y coordinate (y-8-34) is to account for all the odd shaped pixels while the last part is for the pfpixels with a height of four? 

 

Thanks!

[Lillapojkenpåön]

y-8 is the top of the player

 

The reason you remove 16 (or 17) from playerx is beause playerx starts from edge of the screen

while pfx starts 16 pixels from the left, and you want them to be at zero at the same time

 

same exact thing with playery, because of the long pfpixel the fourth pfpixel is very far down

playery will be way to much when it gets down there for them to line up, so we remove that distance

before sending it to pfread

 

 

the division makes playerx and y values increment and decrement slower when moving

since there's 160 x positions but only 32 horisontal pfpixels

and 88 y positions but only 11 pfrows

 

160 - 16 on each side divided by four is 32

88 divided by eight is 11, your'e using divide by four since you have 22 row resolution on that part of the screen

 

Here's some stuff that might be helpful if you want to change the values to fit your sprite

/*

for an 8x8 pixel sprite as in this case

leftmost pixel = player0x - 17

rigtmost pixel = player0x - 10 (-17 + 7, the eight pixel is seven pixels away from the first)

top pixel = player0y - 7 (sometimes - 8 works better)

bottom pixel = player0y (sometimes - 1 works better)



one pixel to the left of sprite = player0x - 18 (-17 - 1)

one pixel to the right of sprite = player0x - 9 (-17 + 8 = -9)

one pixel above = player0y - 8 (-9 if - 8 works better for top pixel)

one pixel bellow = player0y + 1 (+0 if - 1 works better for bottom pixel)



  ; 00111100  7

  ; 01111110  6

  ; 11000011  5

  ; 10111101  4

  ; 11111111  3

  ; 11011011  2

  ; 01111110  1

  ; 00111100  player0y




  ; player0x

  ; ↓

  ; ↓1234567

  ; ↓

  ; 00111100

  ; 01111110

  ; 11000011

  ; 10111101

  ; 11111111

  ; 11011011

  ; 01111110

  ; 00111100



*/

 

Cleaner

collision_prevention_7.bas

 

[KevKelley]

That probably would have taken me a lot longer to figure out. The code you posted before is very interesting to look at and I was checking it out on my lunch. Thank you for your explanation. I was a little fuzzy after reading the forums and programs, as I knew there was conversion that needed to happen but didn't realize the other checks that would be needed to make it run smoothly.

[KevKelley]

I still cannot thank you enough with that code.  I can see what you mean by me requiring a lot more checks than my single check I had started with.  I had thought that since collision with the pfpixels was only needed on the bottom of the screen I could make a bounding box and when in that box I would have collision detection, otherwise collision detection would be turned off so that you would not inadvertently remove the playfield. The sticky collision only resulted when I moved the drawscreen, otherwise it seemed to work as intended.

 

I am still trying to wrap my head it, as the checks are more complex than anything I had done before and it is taking me a bit to follow the code to see how each line affects the interactions on screen.  I think i get the principles behind it all but I had a question:

 

I notice the movement of the player0 sprite stops halfway up.  If I were to have it continue moving up, would I have to perform more checks because the pfheights are different? Would it still be possible to use a method similar to the one I initially used since the only real interactions occur on the bottom, only getting conversions for the when the player is on the bottom of the screen near the generating pfpixels?

 

I was looking at the checks for each direction like this:

 

up
   if !joy0up then goto movedone
  
   temp3 = (player0x - 17) / 4 ;player xPos
   temp6 = (player0x - 10) / 4 ;xPos +7, rightmost pixel of sprite


   temp4 = ((player0y - 9) - hmm2) / hmm ;yPos above player, using 8 looks wrong since the player can only be placed every 2nd scanline

 if temp6 > 19 then temp1=100 else temp1=3 ;after that xpos, the floor is the 8th pfrow, else it's 10
 

 if temp4 > temp1 && temp4 < 10 then goto _box4
 
_playfield4
   if pfread(temp3, temp4) then player0y = (temp4 * hmm) + 16 + hmm2 - 4 : goto movedone
   temp3=temp3+1
   if pfread(temp3, temp4) then player0y = (temp4 * hmm) + 16 + hmm2 - 4 : goto movedone 
   if pfread(temp6, temp4) then player0y = (temp4 * hmm) + 16 + hmm2 - 4 : goto movedone 
   goto _skip_box4
_box4 
   if d{0} then _playfield4
   if pfread(temp3, temp4) then pfpixel temp3 temp4 off : d{0}=1 : goto movedone 
   temp3=temp3+1
   if pfread(temp3, temp4) then pfpixel temp3 temp4 off : d{0}=1 : goto movedone 
   if pfread(temp6, temp4) then pfpixel temp6 temp4 off : d{0}=1 : goto movedone 

_skip_box4
   if _player0y - speed > 50 then _player0y = _player0y - speed else _player0y = 50

 

[Lillapojkenpåön]

Having no collision detection with the pillars up there was the best I could do

 

collision_prevention_9.bas

[Lillapojkenpåön]

Btw, there's alot of overcomplicated code

 

in down you can change this

  ;if temp6 > 19 then temp1=0 else temp1=10 ;after that xpos, the floor is the 8th pfrow, else it's 10

  ;if temp4 < temp1 then goto _box3 ; if ypos is not at the floor, treat pf as box

to this

       if player0x < 91 && player0y < 72 then goto _box3

 

in up change this

 ;if temp6 > 19 then temp1=100 else temp1=3 ;after that xpos, the floor is the 8th pfrow, else it's 10

 ;if temp4 > temp1 && temp4 < 10 then goto _box4

to this

     if player0x < 91 then goto _box4

[KevKelley]

Wow. I will have to check this out. Today was my day off so I was gonna take a good hard look at it. The pillars at the top are actually the truck bays so my plan was that one to use pfhline across each space once a full pallet (missile1) crosses over it.