Box2D progress

Here are the things I picked up today:

- Mercurial / TortoiseHG installed
- Assembla repo created
- Learned how get Mercurial to store my Assembla password:

1) From the Hg workbench right-click the project > settings > global settings tab > edit file.  Enter the following:

[extensions]
mercurial_keyring=

Hit save.
2) repo settings > edit file

Set the https URL to https://username@repo.path.com

My hgrc looks something like this:

[paths]
default = https://my_assembla_user_name@hg.assembla.com/ProjectName

- Learned that the libgdx .processEvents method (which implements calls to keyDown, etc.) is executed prior to render().  So, it should be safe to modify Box2D world objects (create, delete, etc.) from the context of a keypress, since the step() method is executed from within the render() method.

- Learned that the BeginContact() method of the libgdx Box2D implementation is executed in the context of the step() method.  It is NOT safe / allowed to modify world objects from within BeginContact.  Since I want to create / delete / whatever as a result of contacts, I created an ArrayList that is modified based on contact.  Then, after the step() resolves, this list is iterated through and actions are performed.  I maintain separate lists depending on the type of actions I want to perform. 
For example, I have one list that operates on bullets hitting objects.  I have another list that operates on special objects interacting with other objects -- the operations of which are completely different than what happens when bullets are resolved.

In my render() method, following step(), I loop on the list not being empty, and simply removing one element at a time.  Since the libgdx mainloop() is single-threaded, operating on these lists shouldn't need to be synchronized and I don't need any sync wrapper methods / protected methods for list operations.


- Discovered a stoopid mistake where I did a shape.dispose() on a shape attached to a body that had been created in the world.  The net result was that my application would crash and I'd get a "pure virtual function called".  Das ist bad, ja!

- Discovered another stoopid mistake where I destroyed a body in one resolution step without updating locally maintained object references.  Then, as I attempted to modify those same (now destroyed) objects, I got to watch the application crash hard again in the middle of a Box2D step.  Yuck.

- Got a better grasp of some simple vector methods.  To get a vector's normal, swap the x & y coordinates, and negate the new y-coordinate.  This effectively translates the vector 90 degrees anticlockwise.  Doing this again rotates that vector by another 90 degress.  Two more times brings you back to the original position.  Certainly information you can use to impress the ladies.

- Got a better understanding of collision filtering.  Bodies that have the same positive group index number always collide.  Bodies that have the same NEGATIVE group index number NEVER collide -- they just pass through each other.  This is helpful if you have a bullet object that you don't want to hit the player body if he is aiming down at his feet.

- Bodies that are connected via joints affect the overall velocity of the jointed body.  In my game, I teleport around objects.  Turns out that when I did my transform to move the object and affect the velocity, I only did it to one of the objects in a jointed system.  The velocity ended up being slower than I predicted until I realized my secondary body was affecting things too.

- Had the assumption that a dynamic fixture with zero density was a sensor.  Not so.  You have to explicitly set the sensor flag to true.  My player body now sinks into the floor because the circle bottom sensor does not evoke any collision contacts.  This is what I originally expected, but figured I must have misunderstood something. 

- I've got the rudiments of my game working.  I need to clean some things up and get rid of some glitches due to my processing multiple contacts in the bullet list described above.  After that, I'll be expanding my test arena to include some kinematic bodies.

Some major refactoring is in order, but I'm holding off with doing that after I've got some more of the game ideas implemented and understood -- things like buttons, doors, anti-grav fields, etc.