How to check inverted colitions?

J

Jeshuakrc

Guest
So, I don't need this:
Code:
!place_free(x,y)
Because all what it woould do is to return true once there were no pixels at all in contact with the mask. What I actually want is a way to know when one or more pixels of my sprite isn't touching the mask. I used to achieve that by runing:
Code:
for(){
    for(){
        if(colition_point()){
            if !colision_point(){
                return 1
                }
            }
        }
    }
But I don't like too much the idea of cheking by code every single one of the pixels of my sprite to see if one or more of them isn't coliding. Any other much "elegant" way to achieve that?
 
T

TeamSteeve

Guest
If you need pixel perfect detection for both your sprite and mask, I'd suggest not designing it that way in the first place. It's awfully slow to check every pixel in the sprite for a collision.
Otherwise you could check the 4 sides of the sprite bounding box to see whether any of them are outside the mask.
 

NightFrost

Member
If the mask you're interacting with is rectangle... consider this: a rectangular mask that exactly covers a sprite needs to be wholly inside another rectangle for all of the sprite's pixels to be inside the other rectangle. Conversely, if the sprite's mask is not completely inside another rectangle, one or more pixels must be outside the other rectangle. You can use rectangle_in_rectangle to check if one rectangular area is completely inside another.
 
J

Jeshuakrc

Guest
If you need pixel perfect detection for both your sprite and mask, I'd suggest not designing it that way in the first place. It's awfully slow to check every pixel in the sprite for a collision.
Otherwise you could check the 4 sides of the sprite bounding box to see whether any of them are outside the mask.
If the mask you're interacting with is rectangle... consider this: a rectangular mask that exactly covers a sprite needs to be wholly inside another rectangle for all of the sprite's pixels to be inside the other rectangle. Conversely, if the sprite's mask is not completely inside another rectangle, one or more pixels must be outside the other rectangle. You can use rectangle_in_rectangle to check if one rectangular area is completely inside another.
The thing here is that I indeed need a pixel perfect detection, guys
 

NightFrost

Member
If you need pixel-perfect for both and find out if there's no collision for at least one pixel, then there's no other way besides running through every pixel. You can speed up by doing rectangle comparison first, because if they don't overlap then there's obviously non-colliding pixels. If the sprites don't animate, I guess you could speed up by precalculating into arrays and then comparing those instead. Well, I suppose you could do that even if they animate, if you're up to writing a system to manage everything related to that.
 

kupo15

Member
If you need pixel perfect detection for both your sprite and mask, I'd suggest not designing it that way in the first place. It's awfully slow to check every pixel in the sprite for a collision.
Otherwise you could check the 4 sides of the sprite bounding box to see whether any of them are outside the mask.
Can you elaborate what you mean by "its awfully slow?" I simply don't understand how slow "awfully slow" is and what the issue is. I always see people warning against precise collision using hyperbolic language (hyperbolic where programming is concerned) whenever this topic comes up and I don't understand why its said with this much detest every time. My game is pretty much full of precise collision checks, in HD and I have yet to experience any crippling effect of precise collision. I would be interested to see how much time the debug says its taking but precise collision hasn't been a hindrance to me at all

Plus, GMs collisions system already culls out objects that don't overlap bounding boxes to make things more efficient so no need to additionally check with simpler collisions
 

NightFrost

Member
OP wants to know if some of the pixels on sprite A aren't overlapping pixels on sprite B. Which is another way of asking if sprite B completely obscures sprite A. Precise collision check will only tell that an unknown quantity (one or more) of pixels are overlapping, which is not enough information.
 
T

TeamSteeve

Guest
Can you elaborate what you mean by "its awfully slow?" I simply don't understand how slow "awfully slow" is and what the issue is. I always see people warning against precise collision using hyperbolic language (hyperbolic where programming is concerned) whenever this topic comes up and I don't understand why its said with this much detest every time. My game is pretty much full of precise collision checks, in HD and I have yet to experience any crippling effect of precise collision. I would be interested to see how much time the debug says its taking but precise collision hasn't been a hindrance to me at all

Plus, GMs collisions system already culls out objects that don't overlap bounding boxes to make things more efficient so no need to additionally check with simpler collisions
Well it's all relative and depends greatly on the specifics of each game and the hardware it's running on.

I have to admit I haven't tested it in a while, but previously it was pretty clear that unoptimised collision checking causes significant CPU usage for me, and checking each pixel of a sprite is SUPER slow. Try it yourself.
 
Top