PocketMatrix

What do you mean by overlapping? PocketFrog can tell when 2 surfaces are overlapping using Rects to spot the collision. One of my articles covers this ( see http://www.sundialsoft.co.uk PocketFrog pages )

I've been wondering about this myself...

If you do a pixel-based collision detection, probably most likely after a bounding rectangle algo indicates a collision (to gain some increased accuracy in detection), it seems to me that it will be slightly more difficult than it should be (or than I'd like it to be anyway!)...

When you load an image, the RGB values you wind up with on a surface aren't necasserily the same as what is really in your image. For instance, RGB 255/255/255 I think (someone check me!) actually winds up being 63/63/63. In other words, if you have a solid white rectangle and you load it and do a GetPixel based on it later, you won't get the result 255/255/255 as you might expect, but instead 63/63/63.

So, the complication arises in that you have to take this into account when doing your checks. You'll have to pre-determine what the sorface values will be on the surface based on your actual source image.

Alternatively, can you reconstitute the original values? I assume not, seems obvious that you are losing numeric accuracy when the "downshift" occurs, you can't get that back later?

Am I missing something obvious here? That wouldn't surprise me, but I'm pretty sure I'm not.

Hi

255, 255, 255 RGB will be 31, 63, 31 RGB on a 565 format, which most (if not all?) Pocket PCs are.

But, I always thought pixel collision detection was done with binary masks. AND the masks together and if any pixel is 1 then there is a collision.

Pam

Ah, your right, forgot it's 565... Argh.

Anyway... I know there are a number of different collision detection methods... I'm actually not familiar with the binary mask method, could you elaborate?

The way I've always done it, in the instances where pixel-level detection is required (I tend to use bounding circles alone most of the time), is to look for specific RGB values... for instance, a space ship colliding with an asteroid, I would have an outline of one or both of them be a specific color (assuming a black background for space, maybe I'd make the outline RGB 1/1/1), then just check for that in the pixels where the movement will be (i.e., ship moving to the right I'd check the pixels at shipX + shipWidth + 1 for my 1/1/1 RGB values before I actually do the move, going along the right edge of my ship so I'm only testing a single column of pixels). It's easy enough to code and relatively efficient when moving in the four cardinal directions, diagonals tends to be just a bit more difficult to code, but not terribly so.

I'm absolutely certain that's not the best way efficiency-wise, but depending on the sizes of the graphics and other factors it may not hurt your performance to a degree that matters.

But I'm interested in other techniques for sure...

I haven't really thought this through yet, so maybe it isn't the best way to do the collision detection, but what I would do is create a pixel shader to blit the ship where all 'background' is 0 and all 'foreground' is non-zero creating a binary mask. I would then use another pixel shader to blit 2 masks together, ANDing the values. You would have to blit them in their appropriate relative locations, of course. Then check to see if the result has any non-zero values. If so, then a collision has happened (haven't thought how best to do this test yet).

Anyway, that's my thought on it. Perhaps not the most efficient way either, but does handle cases where the two sprites (or whatever) are moving more than a single pixel at a time.

Pam

Well, just thinking some more, no need for 2 pixel shaders or masks. Should be able to have a pixel shader that ANDed the src and dest pixels, then do the final test for non-zero values.

Pam

Would anyone be intrested if i published a pixel perfect collision detection function here?

As with most graphic operations, you will get at least a 2x performance boost by simply checking what pitch value is smaller (x or y) and use that for the inner loop. You also might want to adjust the pixel pointer so that the pitch value of the inner loop is positive. I would guess that the performance of your loop would improve around 2.3 times on devices such as the IPAQ 36xx and 38xx series (with their 90 degree display rotation) if you do this...