HTML and CSS Reference
Objective complete - mini debriefing
A sensor fixture allows a body to pass through it. We may not be able to see the sensor,
but the contact listener tells us when a fixture collides with the sensor.
The contact is made with ContactListener . Box2D informs us that there is contact
between the two fixtures. In the BeginContact funcion, we get the two ixtures that
collide with each other. We need to check which bodies they are and code our custom
logic. By using GetBody on the fixture, we can get the body. With the GetUserData
method, we have access to the custom data that we set to the body. We can only
determine what acion is to be taken ater knowing which objects collide.
The BeginContact funcion provides the two contacing
fixtures: fixtureA and fixtureB . We guarantee to obtain
the two fixtures when the contact occurs, but the order of the
fixtures is not guaranteed.
The contact listener, by default, is triggered by every body's collision. We need to filter the
result and only focus on what we are interested in. Here, we are interested in two collision
pairs: the ball/hoop and balls/boundary pairs.
There are more controls on the object's contacts. The following URL explains the anatomy
of a Box2D collision. The post targets the C++ ediion but the same concept also works in
The Box2D engine knows that eventually we need to atach our own data to each body. That's
why it provides a User data on each object. We can use the SetUserData or GetUserData
methods to access custom data. We set an object in the boundary so that we can idenify it
from other bodies when we handle the collision. Otherwise, we cannot tell which bodies
cause the collisions.
SetUserData and GetUserData methods exist is because these
methods were ported from strictly typed OOP languages—C++ and
AcionScript. These languages require a dedicated user data property
to be predeined in the class body and expose a get/seter funcion
for the programmer to use.