The problem with per-pixel collision detection is that 1. it can be very slow and 2. your graphic design can have a lot more impact on your game mechanics than you would like. It is usually better to try to approximate the collision zones of the objects in your game with simple geometrical shapes.
The last time I made a game with an isometric perspective, I found it very useful to calculate all the game mechanics in orthogonal perspective. So on the game logic layer, all tiles were still rectangular. The transformation of all the orthogonal logic coordinates into the isometric screen perspective didn't happen before the rendering loop. That made many things a lot easier.
But if you really want to handle everything in screen coordinates, then you don't have bounding boxes, you have bounding rhombuses. Fortunately, these are not much more difficult to check for collision with each other than boxes.
- The distance between two points in the upleft -> downright diagonal is
abs((x1 + y1) - (x2 + y2))
.
- The distance between two points in the upright -> downleft diagonal is
abs((y1 - x1) - (y2 - x2))
- Note that if your tiles are not as wide as they are high, you need to multiply all the x-coordinates in the above two formulas with half your tile-width and all the y-coordinates with half your tile-height.
- You have a collision in the same situation where you have a collision between two boxes: If the absolute value of the difference on both diagonals is smaller than the sum of the distance between center and edge of both rhombuses on the respective axis. Or in code, if both distances are smaller than
sqrt(tilewidth * tilewidth + tileheight * tileheight)
(which is, as you might notice, a constant you can hardcode).