safe pointers in Box2d
I am attempting to rewrite my game to use Box2d and am having a lot of trouble.
The latest issue I ran into is how to handle collision response safely.
The problem is that since Box2d uses custom memory management, you are forced to use raw pointers. I can't figure out any way to organize the logic without risking the possibility of dangling pointers.
How do you deal with this? Everything about Box2d seems so confusing. Half the time, I have to check the source files just to figure out how to do something.
I have minimal experience with Box2D. The experienced Box2D users over at the Box2D forums could probably help you; Erin Catto, the creator of Box2D, frequents the forum as well.
There are a few different ways you can do this but the one that I have found the cleanest is to buffer the contacts in a list and process them latter like the wiki recommends.
Quote:Original post by dabski
There are a few different ways you can do this but the one that I have found the cleanest is to buffer the contacts in a list and process them latter like the wiki recommends.
This is the way to do it with any of the physics libaries really. Bodies should only be deleted before/after a physics timestep. Most likely your game entity has a pointer to the physics body and checked if its still alive after a physics update. So when you remove the entity remove the physics body and you have no problems about memory leaks.
Just to expand on the other comments:
Buffer your contacts during the physics step Process them afterwards If processing contacts requires destroying bodies or joints, flag these until you have processed all contacts Destroy all flagged bodies and joints
B2D does provide a listener that you can use to be informed when bodies are destroyed, but I've found just using the above system seems to work okay.
It is no good buffering contacts then destroying bodies while you process the contacts though, as that is bound to lead to dangling pointers in your buffered contacts list.
B2D does provide a listener that you can use to be informed when bodies are destroyed, but I've found just using the above system seems to work okay.
It is no good buffering contacts then destroying bodies while you process the contacts though, as that is bound to lead to dangling pointers in your buffered contacts list.
On further inspection, it turned out that I was already using the mark and delete later trick.
But what if one of the entities wants to retain a persistent reference to the collision partner through multiple timesteps? I can try to redesign things to avoid this, but it seems like it will eventually be unavoidable.
But what if one of the entities wants to retain a persistent reference to the collision partner through multiple timesteps? I can try to redesign things to avoid this, but it seems like it will eventually be unavoidable.
I have a list of std::pair's of collision bodies that are in contact that is kept the entire length of the game. When you get a on contact callback you check to see if those two bodies are already in the list. If they aren't add them to the list then call the oncontact function to the entities. This would add body B to an internal collision list of body A and do whatever else needs to be done on collision. When you get a contact ended message you remove the pair from the list and notify the entities. When you delete an entity and it tells the physics world to delete the body you go through that list and find any pairs it is in then remove them and notify the other entity it has lost a contact.
Actually my method is pretty much ripped off Game Coding Complete 3rd edition. It uses Bullet but the process is the same.
Actually my method is pretty much ripped off Game Coding Complete 3rd edition. It uses Bullet but the process is the same.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement