Author Topic: Pixel perfect collision testing  (Read 7067 times)

0 Members and 1 Guest are viewing this topic.

Offline Yeong

  • Not a bridge
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3739
  • Rating: +278/-12
  • Survivor of Apocalypse
    • View Profile
Pixel perfect collision testing
« on: March 08, 2012, 06:58:13 pm »
I'm just wondering if it's possible with axe bitmap or sprite or stuff.
I have no idea where to start from. help?
« Last Edit: March 08, 2012, 06:58:34 pm by TBO_Yeong »
Sig wipe!

Offline parserp

  • Hero Extraordinaire
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1455
  • Rating: +88/-7
  • The King Has Returned
    • View Profile
Re: Pixel perfect collision testing
« Reply #1 on: March 08, 2012, 06:59:56 pm »
You could always do it the HARD way like I did in swords. :P

Code: [Select]
If X>stuff and X<stuff and Y>stuff and Y<stuff

Offline Yeong

  • Not a bridge
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3739
  • Rating: +278/-12
  • Survivor of Apocalypse
    • View Profile
Re: Pixel perfect collision testing
« Reply #2 on: March 08, 2012, 07:00:24 pm »
but... what if sprite is complicated and it's 24x16?
Sig wipe!

Offline LincolnB

  • Check It Out Now
  • LV9 Veteran (Next: 1337)
  • *********
  • Posts: 1115
  • Rating: +125/-4
  • By Hackers For Hackers
    • View Profile
Re: Perfect pixel collision testing
« Reply #3 on: March 08, 2012, 07:01:30 pm »
Do you remember the engine I posted in the Seeker thread a while ago? Probably not, well anyways here it is:

http://ourl.ca/14386/270062

^^That basically has pixel perfect collisions, it's not tilemap based like most. However, the source is moderately ugly and inelegant - for example I toyed around with weird stuff like 8x inflation and the like.
Completed Projects:
   >> Spacky Emprise   >> Spacky 2 - Beta   >> Fantastic Sam
   >> An Exercise In Futility   >> GeoCore

My Current Projects:

Projects in Development:
In Medias Res - Contest Entry

Talk to me if you need help with Axe coding.


Spoiler For Bragging Rights:
Not much yet, hopefully this section will grow soon with time (and more contests)



Offline Yeong

  • Not a bridge
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3739
  • Rating: +278/-12
  • Survivor of Apocalypse
    • View Profile
Re: Pixel perfect collision testing
« Reply #4 on: March 08, 2012, 07:37:53 pm »
But the problem is that the sprite will be going through another sprite, not just a boundary. D: Also, the sprite is not "boxy".
That's why I'm having some problem.
Sig wipe!

Offline nxtboy III

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 795
  • Rating: +26/-1
  • NXT!
    • View Profile
    • Program NXT
Re: Pixel perfect collision testing
« Reply #5 on: March 08, 2012, 09:05:10 pm »
is there pxl-test in Axe?

Offline parserp

  • Hero Extraordinaire
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1455
  • Rating: +88/-7
  • The King Has Returned
    • View Profile
Re: Pixel perfect collision testing
« Reply #6 on: March 08, 2012, 09:05:28 pm »

Offline nxtboy III

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 795
  • Rating: +26/-1
  • NXT!
    • View Profile
    • Program NXT
Re: Pixel perfect collision testing
« Reply #7 on: March 08, 2012, 09:08:12 pm »
???
Then why not use that for pixel-perfect collision?

Offline parserp

  • Hero Extraordinaire
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1455
  • Rating: +88/-7
  • The King Has Returned
    • View Profile
Re: Pixel perfect collision testing
« Reply #8 on: March 08, 2012, 09:09:45 pm »
I'M not sure if TBO wants collisions like player movement, or collisions with the map, such as spikes, etc.

Offline Yeong

  • Not a bridge
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3739
  • Rating: +278/-12
  • Survivor of Apocalypse
    • View Profile
Re: Pixel perfect collision testing
« Reply #9 on: March 08, 2012, 09:15:24 pm »
sprite vs sprite.
detects collision if even 1 pxl is crossed
Sig wipe!

Offline chattahippie

  • LV6 Super Member (Next: 500)
  • ******
  • Posts: 358
  • Rating: +27/-0
  • Super Member! :D
    • View Profile
Re: Pixel perfect collision testing
« Reply #10 on: March 08, 2012, 09:21:44 pm »
How about checking to see if your sprites are within distance of each other

If {2nd sprite location} - {1st sprite's location} < 16 (or whatever number)
Do Stuff
End

Or

If {1st sprite location} + (sprite size) >= {2nd sprite location}

Would those work?

Offline nxtboy III

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 795
  • Rating: +26/-1
  • NXT!
    • View Profile
    • Program NXT
Re: Pixel perfect collision testing
« Reply #11 on: March 08, 2012, 09:21:54 pm »
So just add another buffer for different types of pixels, like a spike pixel, etc

EDIT: Why not do this: http://ourl.ca/15431
« Last Edit: March 08, 2012, 09:31:15 pm by nxtboy III »

Offline Quigibo

  • The Executioner
  • CoT Emeritus
  • LV11 Super Veteran (Next: 3000)
  • *
  • Posts: 2031
  • Rating: +1075/-24
  • I wish real life had a "Save" and "Load" button...
    • View Profile
Re: Pixel perfect collision testing
« Reply #12 on: March 16, 2012, 06:41:10 am »
This is an odd solution, but it might be fast enough to work.  Consider the following situation:  Your foreground layer is white everywhere there is no collision, and dark everywhere that you can collide, this is before the player is drawn of course otherwise there would always be a collision.  Now, do a pt-get() on the location you plan on drawing the sprite.  You can now scan this region R and the original sprite S and if ever the boolean operation "S and R" is true, you have a collision!  Here is some sample code:

Code: [Select]
:.Example use
:CHECK(X,Y,Pic1)

:Lbl CHECK
:pt-Get(r1,r2)->R
:For(A,0,7)
:  ReturnIf {R+A} and {r3+A}
:End
:Return 0

This can be optimized slightly, but this should make clear what is going on in the code.  Keep in mind this code only works assuming my original condition.  You might have to use another buffer for the sprite "collision masks" if you are already double buffering prior to spriting.
« Last Edit: March 16, 2012, 06:43:54 am by Quigibo »
___Axe_Parser___
Today the calculator, tomorrow the world!

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Pixel perfect collision testing
« Reply #13 on: March 16, 2012, 08:42:13 am »
Here is another method I have been discussing quite often over the past few days and made an example of. It is what Quigibo mentioned in his last few lines, so here is what it looks like... If you have room for another buffer, you will want to draw sprites twice-- once on the viewable buffer and again on the "collision" buffer. For example, if I draw this sprite on the buffer shown on the LCD:

Then I want to draw the hit-box region on the other buffer:


Now all you do for collision is pxl-Test( on that buffer. So here I will pause to explain why this is better:

Say you have a huge monster or kill zone that is like a circle bigger than your sprite. Now say you go inside that area and pixel test for collision-- you will get nothing. However, with that idea above, you will just fill in the hit region with pixels on.
This method can also be applied to creating several layers such as a collision buffer, killzone buffer, warping buffer, et cetera-- and it works quickly.
Also, there are times where you will want a collision zone that does not necessarily have pixels shown. Since the other buffer is not displayed, you are fine :)

Finally, here is an example (sorry, it isn't in Axe, but it is the same concept):

Offline hellninjas

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 625
  • Rating: +17/-0
    • View Profile
Re: Pixel perfect collision testing
« Reply #14 on: March 16, 2012, 02:59:45 pm »
Do you remember the engine I posted in the Seeker thread a while ago? Probably not, well anyways here it is:

http://ourl.ca/14386/270062

^^That basically has pixel perfect collisions, it's not tilemap based like most. However, the source is moderately ugly and inelegant - for example I toyed around with weird stuff like 8x inflation and the like.
This helped me a bit, but i read parser's post :| (sorry!)
Anyways, how would you also do left, right, and above the sprites check?