Makers_F

It doesn't matter. It depends on the coordinate system. It can even be the centre. Try to understand the concepts, not the single example! Replace "left bottom" with "top-left", "center", "a point a hundred times the dimension of the sprite away from the sprite" and it will still be corrected! The transformation translate a whatever point in the local coordinate system to the world coordinate system

The position is taken into account by the transformation. The transformation matrix contains the translation, rotation, skew and scale. This means that if you multiply {0,0} (the left bottom corner of your sprite) for the matrix of this sprite, it will give the coordinates of the point in the world coordinate system which touches the left bottom corner of your sprite. This is valid for every point of the sprite

I searched for a solution to the same problem a few months ago. I found a fantastic work from microsoft.
It is the fastest pixel perfect collision idea i have found, and support whatever affine transformation(but you need a transformation matrix)


http://xbox.create.msdn.com/en-US/education/catalog/tutorial/collision_2d_perpixel_transformed


The standard idea to support rotations is to work in the local space of the sprite A and bring the sprite B in local A space.

Then, microsoft suggests to transform the X and Y versor of A local space to B's one, and then just add the transformed versors to the B's local transofrmation currently checked coordinate, in order to make 2 additions instead of a matrix multiplication


The archive in the link contains a better explaination, but i hope you can get a grasp of what i meant.


Here's my implementation. It works really nice even on mobile hardware. Obviously you can't abuse pixel perfect collision
https://github.com/MakersF/AndEngineCollisionsExtension/blob/master/src/com/makersf/andengine/extension/collisions/pixelperfect/PixelPerfectCollisionChecker.java

As waterlimon stated, use pixel perfect collision only if it is the only one that make sense (you have sprites that should have holes and you must check against point that can potentially be smaller that that holes. Or something extremely unregular)

I have the 4 vertices of the rectangle representing my sprite.
Since i want to enable pixel perfect collision i need to make the fewest check per pixel possible, thus the choice of finding the exact bounding box of the intersecting area.
In addition to the bit mask of the sprite, i have subdivided the rectangle in regions of 32x32 pixels, and store if they are empty, full, or half-filled (so that if a half filled region of a sprite maps to an empty region i can skip 1024 checks and say that they don't collide, and if it maps to a full region i can skip again 1024 checks and say they collide). So, having the bounding box axis aligned to the local axis of the rectangles make the code of checking the square sub-region far easier and more readable.

I'll look into point vs convex polygon, but i'm curious about the Minkowski sum. Can you explain a bit further?