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

Yeong · « **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?

parserp · « **Reply #1 on:** March 08, 2012, 06:59:56 pm »

You could always do it the HARD way like I did in swords.

Code: [Select]

If X>stuff and X<stuff and Y>stuff and Y<stuff

Yeong · « **Reply #2 on:** March 08, 2012, 07:00:24 pm »

but... what if sprite is complicated and it's 24x16?

LincolnB · « **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.

Yeong · « **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.

Also, the sprite is not "boxy".
That's why I'm having some problem.

nxtboy III · « **Reply #5 on:** March 08, 2012, 09:05:10 pm »

is there pxl-test in Axe?

parserp · « **Reply #6 on:** March 08, 2012, 09:05:28 pm »

Quote from: nxtboy III on March 08, 2012, 09:05:10 pm

is there pxl-test in Axe?

indeed.

nxtboy III · « **Reply #7 on:** March 08, 2012, 09:08:12 pm »

Then why not use that for pixel-perfect collision?

parserp · « **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.

Yeong · « **Reply #9 on:** March 08, 2012, 09:15:24 pm »

sprite vs sprite.
detects collision if even 1 pxl is crossed

chattahippie · « **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?

nxtboy III · « **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

Quigibo · « **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.

Xeda112358 · « **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):

hellninjas · « **Reply #14 on:** March 16, 2012, 02:59:45 pm »

Quote from: buttsfredkin 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.

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?

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

Yeong

Pixel perfect collision testing

parserp

Re: Pixel perfect collision testing

Yeong

Re: Pixel perfect collision testing

LincolnB

Re: Perfect pixel collision testing

Yeong

Re: Pixel perfect collision testing

nxtboy III

Re: Pixel perfect collision testing

parserp

Re: Pixel perfect collision testing

nxtboy III

Re: Pixel perfect collision testing

parserp

Re: Pixel perfect collision testing

Yeong

Re: Pixel perfect collision testing

chattahippie

Re: Pixel perfect collision testing

nxtboy III

Re: Pixel perfect collision testing

Quigibo

Re: Pixel perfect collision testing

Xeda112358

Re: Pixel perfect collision testing

hellninjas

Re: Pixel perfect collision testing