I don't think I need to create a vector of the samples and then examine them all together. I think just iterating along each point will be sufficient.
I'd like to find a way to factor together the collision for free objects and map blocks as well really. I'm wondering if I created a seperate function that took a CRect and a CLayerType as a parameter and did the collision reaction computation, I could then, when a sample detects an object, pass its CRect via the GetRect() method, or if a sample detected a map collison, compute the CRect of the map block in world co-ords on the fly and pass that in.
That sounds a bit feasible actually. Just waffling to myself really.
Actually, it wouldn't be as simple as just stepping along the edge by N pixels, since that could potentially miss the final corner unless the length of the edge happened to be exactly (N*M)+1. I guess I'd need to store the previous point sampled, and at when the loop detected that it had exceeded the length of the edge, check and see if the last point sampled was Length-1 and, if not, sample it.
Shouldn't be too complicated, but seems like a lot of iterating through object lists. I reckon I'm going to have to store blocks that need to be collision-tested like map cells in a different list to objects that can just be bounding box intersection tested, like enemies and pickups.
[EDIT - MORE WAFFLE]
I'm wondering if, when you call CMap::Collides() or CItems::Collides(), they should return a std::vector of all the objects or map cells that a given rectangle collides with. The vector could contain a POD that contained a CRect and a Layer type, plus any other attributes, so that both the Item and Map containers could return the same sort of vector.
The above collision code could retrive this vector for a given rectangle one pixel by edge-length pixels, aligned along the edge of the object we are testing for, which would prevent needing to step along the edge of an object in discrete quantities. The code above could then loop through this vector instead of along the edge.
This would move the complicated bit of working out ALL the map cells that an edge collides with, or ALL the items, into the container classes and mean that the collision code would not need to make such a distinction between map cells and items.
It would also only require one traversal of the object list per edge, instead of one per sampled point with the previous idea, since the Items class could just loop once through the item list and compare each items rectangle to the parameter rectangle, and add the item to the vector if there was an intersection.
The CMap equivalent would still have to step along the rectangle, since the map is grid based, but that would be fairly efficient.
This way, there is no minimum or maxmimum item size and a 132x987 item would happliy collide with a 1x1 particle or vice versa.
I think that is an idea with some promise and will have a look at this tonight. I really want to get this rock solid before moving on because it is already so complicated that I'm sure it will come back and bite me as the game grows in complexity.
I've been playing around with some code in Notepad and I reckon that, as long as neither method called vector.clear(), I could pass the same vector first to the CItems then to the CMap, then run the collision detection once over the vector and not care about whether we are colliding with objects or map cells.
This would move the specific differences between calculating intersections with objects and with map cells into their respective containers, which seems to be a far better approach.
I need to actually go home and try this out, but this seems like a pretty promising approach really. Map cells and objects are entirely different things in terms of their internal representation, but as far as collisions go, they are both defined by a rectangle and a layer type. This approach would present just their common features to the collision code and will hopefully be a lot cleaner.