I got lost with a few kinks added in C10 and the vector stuff and c++ stuff in Ch11.
So Id like to review what is happening by the time we get to the cart that you can move via the accelerometer.
1. Before we only needed to add a cocos2d scene and then a layer to make a screenful of action.
With Box2D we must still create a Scene and Layer but we add the C++ format of Class.h & Class.mm
instead of just .m. We also added a query callback C++ Class that serves the specific purpose of
cycling through all bodies in the [b]box2d world? or something[/b], and tests if there is an intersection,
much like in our original cocos2d intersection tests.
2. We created a base Box2DSprite class in order to give our Box2D bodies a basic blueprint.
It states they all have a body which is settable as a property, inherit from the GameCharacter class
(which inherits from GameObject giving it a changeState & updateStateWithDelta) and they could have a mouseJoint.
3. In PuzzleLayer we just had a PuzzleLayer Class that created all Box2D objects internally with
the bunch of methods createMeteor etc. In Scene4 however, we created a specific Box2D body class, Cart, which has moved
a lot of its own creation-code to its class file, Cart.mm. The cart class has its init method plus a createsBodyAtLocation, a
create the wheels with sprites & a setsMotorSpeed method!
The fact that we outsourced some code differently from the PuzzleLayer is throwing me off. Specifically this part:
body->SetUserData(sprite);
sprite.body = body;
I understand that before, we passed in a specific sprite to the createBodyAtLocation method when creating
i.e., the Meteor. So we could say, that sprite I just passed in, set my new body's userData to it and at the same time,
set my newly created body to that sprite's body {since any sprite derives from the Box2DSprite class we created}.
We then added it to the sceneSpriteBatchNode in the same method.
Calling the Meteor node got the png from the sharedSpriteFrameCache setting the Meteor's DisplayFrame
to that png. Then I ran across:
body->SetUserData(self);
1) Self instead of sprite because now Cart.mm is its own class, its own object.
2) We are getting a pointer to the box2d body for later use in the sensor detecting method.
To understand self one must go to the init call, which in this case is initWithWorld.
Ok, so here we setDisplayFrame to cart, since this is the cart class.
We then say createBodyAtLocation which does the body and fixture setup.
So i kinda see where body->SetUserData(sprite); = body->SetUserData(self);
I believe the problem is that from Chapter 10 on, the detailed explanations of everything ceased, notably.
Also it seems many lines of code are included in one listing, for later use down the line in that chapter.
For example; the listOfGameObjects? Later in Chapter 11 we run into something similar in the ccTouchBegan & Moved methods.
And the kVikingSpriteTagValue is also added in the earlier code without an explanation.
It is used to reference the cart in the final Chapter 12 scene. They are added with some code that is not particularly used because the cart is not moved by touch, it is moved by the accelerometer.