I think what we are considering to be a 'standard contact listener' is a bit different. Typically the contact listener has a BeginContact function inside which you will check what the two fixtures are, and take some appropriate action:
Code: Select all
void BeginContact(b2Contact* contact) {
b2Fixture* fixtureA = contact->GetFixtureA();
b2Fixture* fixtureB = contact->GetFixtureB();
... if sensor touched planet, let the planet know ...
... if bullet touched enemy, make an explosion ...
... etc ...
}
I am not aware of the contact listener class having any 'contacts' member, and whatever this 'MyContact' class is, I have no idea.
Ok that's not quite true... I have seen similar approaches to this many times before, so I guess somebody must have written a tutorial or something that recommended to duplicate and store the information about contacts, and then loop through that every frame to use it. In my opinion this is a bad idea, and I think it is unfortunate that this method has spread over the net so much. There is no need to duplicate the same information when in most cases the vast majority of contacts are of no interest to the game logic, and this method will scale badly for scenes with thousands of contacts (especially if that 'contacts' variable is a std::vector). It also makes things unnecessarily complex to manage, which I think is the root of your problem here.
To answer your other question, yes, contacts for sensors will report BeginContact and EndContact events in the normal way. But since there is no collision response necessary they don't generate PreSolve/PostSolve calls, so they are a bit different in that respect.
Another thing that can occasionally cause trouble here is that if you have just added a new fixture to the world, you might need to run one Step of the world before the BeginContact event shows up.