Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MedO]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

[Psychopath]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

This is the part where they realize that there was an easy way already in existence and a few people hit themselves on the forehead for not noticing it sooner

[notajf]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

This is the part where they realize that there was an easy way already in existence and a few people hit themselves on the forehead for not noticing it sooner

Yep, like when I discovered Python actually had a TCP Server wrapper and there was no reason to use sockets directly.

[Orpheon]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

[Psychopath]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

But a rect is just a mask with a rectangular shape

[notajf]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

But a rect is just a mask with a rectangular shape

Collision checking is quicker with rects

[Orpheon]

Rect collision checking:

Code: [Select]

if range(left1, right1) in range(left2, right2):
{
    if range(top1, bottom1) in range(top2, bottom2):
    {
        return True
    }
}
return False

Mask collision checking involves checking each pixel individually.

[Psychopath]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

But a rect is just a mask with a rectangular shape

Collision checking is quicker with rects

I'm just wondering aloud, wouldn't it be more efficient to do raster-rect collisions instead of rect-rect collisions where there are a shitton of rects to parse through.

[Orpheon]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

But a rect is just a mask with a rectangular shape

Collision checking is quicker with rects

I'm just wondering aloud, wouldn't it be more efficient to do raster-rect collisions instead of rect-rect collisions where there are a shitton of rects to parse through.

The point is we'd have to do the raster-rect collision-ing ourselves. Which I have very little idea how. Also, most rects don't even get considered, they have to be close enough.

[Psychopath]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

But a rect is just a mask with a rectangular shape

Collision checking is quicker with rects

I'm just wondering aloud, wouldn't it be more efficient to do raster-rect collisions instead of rect-rect collisions where there are a shitton of rects to parse through.

The point is we'd have to do the raster-rect collision-ing ourselves. Which I have very little idea how. Also, most rects don't even get considered, they have to be close enough.

You still have to technically parse through all existing rects just to identify which ones are near enough :v

[Orpheon]

Short question, why are you turning collision masks into many many rectangles instead of using pygame.sprite.collide_mask?

Originally, I planned to do that. I went to inform myself and asked around how to collide masks with other stuff. People were telling me using rects for this would be a ton more efficient (if you only check those rects near to you), because if the wallmask was a mask, then everything who should collide with it should be one too.
I kinda trusted them, and also I know my way around rects much better than with masks.

Also, that part is done, as in finished in a very small time. I'm having troubles with the collision response, not with the detection (which is easy and actually quite efficient).

But a rect is just a mask with a rectangular shape

Collision checking is quicker with rects

I'm just wondering aloud, wouldn't it be more efficient to do raster-rect collisions instead of rect-rect collisions where there are a shitton of rects to parse through.

The point is we'd have to do the raster-rect collision-ing ourselves. Which I have very little idea how. Also, most rects don't even get considered, they have to be close enough.

You still have to technically parse through all existing rects just to identify which ones are near enough :v

Of course. But you have to that too with masks, you know. Only you have 6 times more pixels than I have rects, and actually even more because I made the wallmask hollow shells. And it's one if loop to test the x, and if that's correct it's another if loop to test the y.

[Dusty]

So, every player checks to see which rects are around them, right? not just the client?

[Orpheon]

So, every player checks to see which rects are around them, right? not just the client?

Uhh, it's basically like this:

Code: [Select]

with GameObject:
    if collisionRect != -1:
        for (a=0; a<numberOfWallmaskRects; a+=1):
            if abs(wallmaskList[a].centerx-self.rect.centerx) < 50:
                if abs(wallmaskList[a].centery-self.rect.centery) < 50:
                    if self.rect.colliderect(wallmaskList[a].rect):
                        reactToCollision()


[MedO]

So, raster collision checking is slow and rect collision checking is fast. As a result, your own code for raster collision, using thousands of rect collision checks must be faster than the raster collision code in a popular library?

Implementing mask collision in terms of rectangles might be much more feasible if you had even a simple broadphase, but you don't. Your algorithm doggedly looks at every single rect. Thinning out the walls reduces the number of rects dramatically, but did you consider the problem of tunnelling this creates? And there are still thousands of rects left.

The most annoying thing about this is that a proper rect-mask collision code would be much simpler than what you wrote, and much faster too, at least if you assume that the rect is always axis-aligned, but that is always the case in GG2. My recommendation: Look at the first function in http://pygame.org/wiki/FastPixelPerfect for a template, but leave out the check against the second mask since your entire second rect is colliding anyway.

Yes, you look about x AND y now. So what? Our characters are just a few map pixels high and wide, so it is still much less checking than with your code.

All in all, this looks very much like an example of premature (mis)optimization to me. Congratulations - you identified a suspected problem and, before ever checking that it is a real one, pored work into a solution that is probably slower than just using the simple solution: the built-in mask collision checking with a filled rectangular mask.

[notajf]

So, raster collision checking is slow and rect collision checking is fast. As a result, your own code for raster collision, using thousands of rect collision checks must be faster than the raster collision code in a popular library?

Implementing mask collision in terms of rectangles might be much more feasible if you had even a simple broadphase, but you don't. Your algorithm doggedly looks at every single rect. Thinning out the walls reduces the number of rects dramatically, but did you consider the problem of tunnelling this creates? And there are still thousands of rects left.

The most annoying thing about this is that a proper rect-mask collision code would be much simpler than what you wrote, and much faster too, at least if you assume that the rect is always axis-aligned, but that is always the case in GG2. My recommendation: Look at the first function in http://pygame.org/wiki/FastPixelPerfect for a template, but leave out the check against the second mask since your entire second rect is colliding anyway.

Yes, you look about x AND y now. So what? Our characters are just a few map pixels high and wide, so it is still much less checking than with your code.

All in all, this looks very much like an example of premature (mis)optimization to me. Congratulations - you identified a suspected problem and, before ever checking that it is a real one, pored work into a solution that is probably slower than just using the simple solution: the built-in mask collision checking with a filled rectangular mask.

+1