artofwork wrote:You don't need extra bounding boxes or to break up the object any further, the object itself is already a bounding box you can just test collision using colors of the object, why make things more complicated then they have to be?
Remember the object is not an empty entity it has properties that you can set and test against other object's properties.
You can not test collision using colors simply.
To be more specific, you'd need to render to a canvas, loop through either all of it, or just the area where your one bounding box is, the image itself (if doing this per-bullet, it's enough to check near the bullets' edges) check for a specific color. (or a range between some values, either in RGB or HSV or any other space representation)
But who's to say that there won't be any backgrounds that may be a similar color? And when the detection kicks in, it will slow down the game depending on many factors, like the area of the image, and the size and number of bullets.
One solution could be to use multiple canvases, but one canvas for one image would pretty much be a waste of resources.
Using multiple bounding boxes is easier. Less to calculate (4 and-ed booleans if Axis-aligned per box), and it doesn't have any such "hidden" extra requirements like color testing per-pixel.
Also, just a thought, people would probably rather play a game where the hitbox is smaller than the sprite, rather than the reverse, since it would be less fair