Technetium actually has the right idea here if it's pixel-perfect collision detection you're wanting. It's simple and it covers any conceivable shape, without a nauseating clusterfuck of equations. It just needs to be optimized.

First of all, any shape, whatever it is, has extremities. Use those to determine the outermost rectangle of the shape. Do this for both shapes. Then do simple rectangular collision testing to see if their is any overlap. This allows you to trivially reject the majority of scenarios in which the shapes aren't even close to each other.

If the rectangles overlap, *then* you worry about whether or not portions of the 'contained' shapes overlap. At this point you generate an image the size of the intersection of the overlap and render your shapes into it at their appropriate offsets. You end up with a small viewport of the overlapping silhouettes to iterate over with GetPixel() or what have you.

A few things to consider/realize:

1) For circles overlapping rectangles this will often be only small slivers or blocks to iterate over, since once a collision is detected, the collidee is either repelled, blown up, or what have you. Fast moving elements that skip a lot of pixels at once could still cause close to full overlap, but whether or not even that is bad depends on the size of the element. It certainly won't be 320x240 for most people.

2) Tons of elements to be checked for collisions onscreen at the same time could add up, but unless the screen is literally brimming with fast moving elements, the number of pixels iterated over for collision checking with this method will still remain considerably less than 320x240 (even if your game is in 640x480, most likely.)

3) Checking all three color bands of a high-color image when you are dealing with silhouettes is silly. Ideally you would use two primary colors for the silhouettes of the two shapes you were checking against, and do something like an XOR blit into the intersection image. The overlapping areas would always be an exact color, so you'd just need to pick your colors in such a way that you only need to check one band for each pixel to determine the overlap (such as the green band). Lucent blitting can achieve the same goal, ultimately, but of course lucent blitting is slower than XOR. (Dunno if V3 is down with XOR)

4) Instead of generating a new image every time for the intersection, generate a 'scratch' image the size of your largest possible shape to be checked against. When dealing with smaller intersections, clip to the appropriate size in the upper-left quadrant of the scratch image, render your silhouettes, and only iterate over that portion of the image when performing your checks.

So, obviously pixel-perfect testing is not the fastest solution in the world. But when you take all of the above optimizations into consideration, you'll get a far more reasonably performing algorithm.