Still grappling away in my spare time. Been focusing on making the rope behave correctly with moving objects, which has proven to be a bit more complicated than I expected, but seems to be working now.

The grapple bends correctly around objects during any of its states now - extending, locked and retracting - and when it retracts it correctly back-traces its path back to the player, which is quite cool.



It involves a great deal of ray casts and line of sight calculations but these are pretty efficient in Box2D so all seems to be okay.

I discovered though that it fell to bits if the rope passed between two objects that were then pushed together, as the ray casting and line of sight stuff fails then to keep the rope the correct shape. So what I decided to implement was that whenever a rope bend point is created, a small circular fixture is added to the body of the shape it is bending around. This serves to keep the objects slightly apart and keep the raycasts returning the correct values.

You can see these fixtures in the screenshot and at the end of the video when I enable the physics debug drawing.

This proved to enable a bonus feature which will be good for when I start rendering the rope properly, namely that if I also retrieve the (precalculated) local vertex normal of the point that the rope bends around, when I pass the points to the GrappleNode class that actually renders the rope, I can add this normal to the local point (times half the rope "width" or the radius of the additional fixture) before transforming it to world space, so that the rope becomes drawn offset by the right amount.

This means when I come to render the rope as, say, a cylinder, it can be correctly offset from the shapes and have some physical volume rather than being an infinitely thin line.

The signals and slots system I wrote up recently (Event<> and Delegate<>) is working out very well in this project. I wrap b2Body, b2Joint and b2Fixture in my own classes that are re-referenced back to the b2 object via the UserData() method. One tricky thing in a physics engine is implicit destruction, e.g. when a b2Body is destroyed, any attached b2Fixtures and b2Joints are also destroyed implicitly, which can be a pain when you have references to them lying about.

My wrapper classes all emit a destroyed(Type*) event when they are deleted and Box2D provides a destruction listener that is informed when an implicit destruction happens, so I can do something like:class DestructionListener : public b2DestructionListener{public: virtual void SayGoodbye(b2Fixture *fixture){ delete static_cast<Fixture*>(fixture->GetUserData()); } virtual void SayGoodbye(b2Joint *joint){ delete static_cast<Joint*>(joint->GetUserData()); }};
Anything that maintains a reference to a joint or fixture can then deal correctly with the destruction, by nullifying a pointer, or releasing a pointer without deletion if stored in a smart pointer.

Took a bit of work to get all this working correctly, but you can see the tracking in the top of the window where I've been checking none of my wrapper objects are being leaked during the rather complicated flow that happens when I destroy the red cubes while the rope is wrapped around them.

I think rendering a rope volume is probably up next. I'm thinking of creating a cylinder and putting smooth bends around the corners but not entirely sure yet. This is a very much made up as gone along project so no firm plans.

Thanks for reading.