Iphone Developer Technological

Cocos2d Games: PhysicsEditor & TexturePackerPro

Getting an app from idea to finished product is quite a drawn-out process.  As programmers we rarely accept the fact we need help, but thats when tools like these come in.  Tools like PhysicsEditor & TexturePacker are perfect for speeding up the development process of games so that you can focus on the tasks that matter most, the tasks that make a game a winner; game logic.

Pick up these tools today, trust me, your expectations will be more than surpassed! – The sprite sheet creator turns chaos into order – Edit your physics shapes with ease

Iphone Developer Technological

Importing Box2D & Chipmunk into XCode

 am up to Chapter 13 and I have just finished RE-building my project because of minor details I may have omitted and Id like to share with you all and perhaps get cleared up:

1. Importing folders. When importing folders into Xcode, which Ive had experience with Coreplot, Facebook, twitter apis, json libraries and more recently Box2D and Chipmunk folders, there is a difference between copying and not copying if needed. I thought I understood the difference but Im not sure now. When adding a folder to your project, you add it via the finder first and then via Xcode.

Lets take Chipmunk for example:
a. You copy your Chipmunk folder from the drive and paste it INTO your project drive folder (in Finder). i understand this only makes those files readily available to your project, but you must still tell your project “where those files really are, and that they are there for its use”.
b. So you then drag the same folder you just added to your project’s folder on your drive INTO your Xcode GROUP (inside Xcode, not Finder)
c. Sometimes you check that you INDEED WANT the items to be copied (as with Box2D & Chipmunk folders) and sometimes your DO NOT CHECK IT as with GLES-render files.

These are just 2 ways of doing the same thing, right? If you didn’t physically copy the folder in Finder, you want to CHECK the COPY ITEMS option and if you already did, you DONT want or particularly need to copy them in again, right?

However it makes a difference when you are dragging the folder, as in Coreplot, because if you drag the folder from Finder to Xcode Group folders or Finder Folders, you are actually taking the original folder, removing it from its current location and placing it in its new location.

I believe this made a big difference to me right now and I messed up my project so bad i had to rebuild the whole thing. This importing folders thing and the “copy-paste from the pdf” scheme I’ve got going which sometimes copies characters you can’t see but will give you the worst headaches hunting them down! :)

2. Missing cocos2d library from my project. At some point in the project I must have done something differently because unlike the SpaceViking Project I have, the downloaded source code has an extra target. It has a SpaceViking target and a cocos2dlibraries target which I don’t have, yet my project runs fine. Why is that? Plus what does it mean to have 2 targets? Which brings me to my next question…

3. Project vs Target settings. You can set most if not all of the same build settings for the project and for the target. They are indeed different because I believe that if you set one instead of the other, sometimes you get errors and build fails.

Iphone Developer Technological

Box2D – Cocos2d – ObjC Complex Code Design

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 & 
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,  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:

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:


1) Self instead of sprite because now 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.
Translate »