package nape.dynamics

Arbiter

Arbiter representing the state of an interaction between two Bodys. *

* These objects are automatically reused, and you should not keep your own * references to them.

ArbiterIterator

Haxe Iterator compatible iterator over Nape list.

ArbiterList

Nape list of Arbiter type objects *

* Internally this list is at present implemented as a linked list with * object pooled nodes and iterators with various fast paths made for * standard access patterns (For instance accessing successive elements * runs in constant time when using random access functions) *

* Iteration of this list can be done in various ways, but the preferred * way on all targets, is through use of the foreach function: *

 * list.foreach(function (obj) {
 * });
 * 
* This method is inlined so that in haxe no closure will need to be created. *

* In AS3, a closure would need to be created in general, so for performance * reasons you 'may' choose to use iteration as follows: *
 * for (var i:int = 0; i < list.length; i++) {
 *     var obj:Arbiter = list.at(i);
 * }
 * 
*
* NOTE: It is 'not' safe to modify a list whilst iterating over it. * If you wish to remove elements during an iteration you should use the * filter method, for example: *
 * list.filter(function (obj) {
 *     // operate on object.
 *     // ...
 *     return (false if you want object to be removed);
 * });
 * 
*

* In AS3, if you wish to avoid a closure generation, you can perform such * an iteration in a safe manner as follows: *
 * var i:int = 0;
 * while (i < list.length) {
 *     var obj:Arbiter = list.at(i);
 *     // operate on object.
 *     // ...
 *     if (should remove obj) {
 *         list.remove(obj);
 *         continue;
 *     }
 *     else i++;
 * }
 * 
* Or if you are always clearing the list entirely you could write: *
 * while (!list.empty()) {
 *     var obj:Arbiter = list.pop();
 *     // operate on object.
 *     // ...
 * }
 * 

ArbiterType

Enumeration of Arbiter types.

CollisionArbiter

Arbiter sub type for collision interactions.

Contact

Contact point for collision interactions *

* These objects are automatically reused and you should not keep references to them.

ContactIterator

Haxe Iterator compatible iterator over Nape list.

ContactList

Nape list of Contact type objects *

* Internally this list is at present implemented as a linked list with * object pooled nodes and iterators with various fast paths made for * standard access patterns (For instance accessing successive elements * runs in constant time when using random access functions) *

* Iteration of this list can be done in various ways, but the preferred * way on all targets, is through use of the foreach function: *

 * list.foreach(function (obj) {
 * });
 * 
* This method is inlined so that in haxe no closure will need to be created. *

* In AS3, a closure would need to be created in general, so for performance * reasons you 'may' choose to use iteration as follows: *
 * for (var i:int = 0; i < list.length; i++) {
 *     var obj:Contact = list.at(i);
 * }
 * 
*
* NOTE: It is 'not' safe to modify a list whilst iterating over it. * If you wish to remove elements during an iteration you should use the * filter method, for example: *
 * list.filter(function (obj) {
 *     // operate on object.
 *     // ...
 *     return (false if you want object to be removed);
 * });
 * 
*

* In AS3, if you wish to avoid a closure generation, you can perform such * an iteration in a safe manner as follows: *
 * var i:int = 0;
 * while (i < list.length) {
 *     var obj:Contact = list.at(i);
 *     // operate on object.
 *     // ...
 *     if (should remove obj) {
 *         list.remove(obj);
 *         continue;
 *     }
 *     else i++;
 * }
 * 
* Or if you are always clearing the list entirely you could write: *
 * while (!list.empty()) {
 *     var obj:Contact = list.pop();
 *     // operate on object.
 *     // ...
 * }
 * 

FluidArbiter

Fluid interaction subtype for Arbiter.

InteractionFilter

InteractionFilter provides bit flags for low-level filtering of interactions. *

* For a given interaction type, two Shapes will be permitted to interact only if * (shape1.group & shape2.mask) != 0 && (shape2.group & shape1.mask) != 0 *

* There are 32 real groups corresponding to a set bit in the group/mask fields. For instance * a group value of 0x120 corresponds to the 'real' groups 5 and 8 as 0x120 = (1<<5) | (1<<8) *

* Nape provides group/mask for each interaction type. The actual precedence of interactions * is further defined simply as: Sensor > Fluid > Collision. *
* Two static bodies can never interact, and with the exception of sensor interaction, at least one * of the two bodies must be dynamic. *
* Sensor interactions have the highest precedence, followed by fluid and then collisions. * Sensor interaction is permitted only if one of the shapes is sensorEnabled, whilst fluid * is permitted only if one of the shapes is fluidEnabled. *

 * if ((shapeA.sensorEnabled || shapeB.sensorEnabled) && shapeA.filter.shouldSense(shapeB.filter)) {
 *     SENSOR INTERACTION!!
 * }
 * else if (bodyA.isDynamic() || bodyB.isDynamic()) {
 *     if ((shapeA.fluidEnabled || shapeB.fluidEnabled) && shapeA.filter.shouldFlow(shapeB.filter)) {
 *         FLUID INTERACTION!!
 *     }
 *     else if (shapeA.filter.shouldCollide(shapeB.filter)) {
 *         COLLISION INTERACTION!!
 *     }
 * }
 * 

InteractionGroup

InteractionGroups are another way of filtering interactions. *

* InteractionGroups form tree structures which are checked along side InteractionFilters * when deciding if two Shapes should interact. *

* InteractionGroups are assigned to any Interactor (not just Shapes), and two Shapes will * interact only if the most recent common ancestor in the InteractionGroup tree permits it. *

* For the purposes of the search, if any Interactor has no InteractionGroup assigned, we * search up the Compound tree first. *

 *            _Group1
 *           /   |
 *          /  Group2      Group3
 *         /    |    \       |                 Group1
 *     Body1   /      Cmp1   |                 /   \           Group3
 *    /    \  /      /    \  |      ==>    Shp1    Group2        |
 * Shp1   Shp2   Body2     Cmp2                    /    \      Shp4
 *                 |         |                  Shp2    Shp3
 *                Shp3     Body3
 *                           |
 *                         Shp4
 * 
* If we look at which InteractionGroup is used for which Shape following this rule, then * the left graph can be transformed into an InteractionGroup tree on the right and we get * that the MRCA (Most recent common ancestors) are such that: *
 * MRCA(Shp1, Shp3) == Group1;
 * MRCA(Shp2, Shp3) == Group2;
 * MRCA(Shp4,   # ) == null;
 * 
* If we were to set up the groups such that Group1.ignore = false and * Group2.ignore = true; then shapes 1 and 3 would not be permitted to * interact, whilst shapes 2 and 3 would be permitted. *
* As the MRCA for shape 4 with any other is null, then the value of Group3's ignore field * is irrelevant, but the existance of Group3 is not as it serves to otherwise prevent Shape 4 * from being permitted to interact with shapes 2 and 3. *

* InteractionGroup's can be fairly expressive, but they are strictly less powerful than * InteractionFilters. InteractionGroup's have their place however as there is no limit * to the number of Groups you can use.

InteractionGroupIterator

Haxe Iterator compatible iterator over Nape list.

InteractionGroupList

Nape list of InteractionGroup type objects *

* Internally this list is at present implemented as a linked list with * object pooled nodes and iterators with various fast paths made for * standard access patterns (For instance accessing successive elements * runs in constant time when using random access functions) *

* Iteration of this list can be done in various ways, but the preferred * way on all targets, is through use of the foreach function: *

 * list.foreach(function (obj) {
 * });
 * 
* This method is inlined so that in haxe no closure will need to be created. *

* In AS3, a closure would need to be created in general, so for performance * reasons you 'may' choose to use iteration as follows: *
 * for (var i:int = 0; i < list.length; i++) {
 *     var obj:InteractionGroup = list.at(i);
 * }
 * 
*
* NOTE: It is 'not' safe to modify a list whilst iterating over it. * If you wish to remove elements during an iteration you should use the * filter method, for example: *
 * list.filter(function (obj) {
 *     // operate on object.
 *     // ...
 *     return (false if you want object to be removed);
 * });
 * 
*

* In AS3, if you wish to avoid a closure generation, you can perform such * an iteration in a safe manner as follows: *
 * var i:int = 0;
 * while (i < list.length) {
 *     var obj:InteractionGroup = list.at(i);
 *     // operate on object.
 *     // ...
 *     if (should remove obj) {
 *         list.remove(obj);
 *         continue;
 *     }
 *     else i++;
 * }
 * 
* Or if you are always clearing the list entirely you could write: *
 * while (!list.empty()) {
 *     var obj:InteractionGroup = list.pop();
 *     // operate on object.
 *     // ...
 * }
 *