The body is probably nil or invalid when you're making that SetTransform call. Are you sure you're setting the body correctly in the sprite when you create both it and the body?

Have you tried looking at the physics editor sample code to see how that sets things up? It might be easiest to work from that example, since you want to use PE anyway.

Ooohhh I really hate this.

So, I was thinking the right way to do this is to subclass CCSprite. Something like:

JSprite
{
   b2Body *body;
} 

// Move the body when the sprite moves
-(void)setPosition:(CGPoint)position
{
   [super setPosition:position];
   body->SetTransform((b2Vec2(position.x/PTM_RATIO, position.y/PTM_RATIO)), 0);
}
// Do the same for rotation, anchor, etc...

However, I'm getting an EXC_BAD_ACCESS error when it tries to set the transform. Maybe the world isn't initialized. Can anyone give me a rundown of the proper way to structure this for collision detection? I was going to use PhysicsEditor to define a body for each frame, and then use that with the sprites, but honestly this whole thing has been more trouble than its worth. Are there any engines or tools out there that offer better support for frame-specific hitboxes?

It's a memory leak unless you call

delete [] vertices;

when you're done using it.

Move your Box2D files to libs folder which should be in your app folder where all your cocos2D filles are located.then in build settings mention that libs folder in Search paths /Header Search paths .

Ah. And now all of a sudden, I get this error in GLES-Render.mm:

variable length array of non-pod element type 'b2vec2'

What's the proper way to fix this? It occurs on the line:
b2Vec2 vertices[vertexCount];

I can fix it by replacing it with:
b2Vec2 *vertices = new b2Vec2[vertexCount];

My C++ is rusty. am I creating a memory leak with this? Should I have resolved this another way?

Awesome. Got it. There was some old unused test class referencing the class I was using box2d in, and I also had to add the box2d library under Build Phases->Link Binary With Libraries. Thanks for the help guys.

If any of your .m files include any headers (or include any headers that include any other headers) that use C++, you need to make those .mm files so that they compile with the Objective C++ compiler. So, other way around from what you were saying about box2d including headers. There's no disadvantage I'm aware of to using .mm for all.

If you use the standard C++ library, you need to link with it, but I guess the C++ compiler does that automatically, so ignore that comment for now.

I was only selectively making .m files into .mm, in this case the HelloWorldLayer.mm. What is the rule for converting these .mm files? Is it if the file including box2d includes another class, I have to make that class .mm as well, or is it the other way around (other classes including HelloWorldLayer must be .mm)? Is there any disadvantage to using .mm files at all?

Also, how would I include the c++ dylib? I haven't seen mention of that anywhere.

Well, that indicates that the standard C++ headers aren't being found (assuming you're including things like <cassert> where you're referencing them). I'd expect that to be because you've included a header from a .m instead of a .mm. Are all of your files .mm now? If not, do any of the .m files include a header (or another header, and so on) that includes a box2d or other c++ header? If so, that's the issue.

Also, you haven't gotten there yet, but you'll want to make sure you link with the standard C++ dylib.

Any ideas?

Here's how my project is set up:
http://sleekmedia.com/Misc/config2.png

Basically, I dropped cocos2D into my project as a separate target so that I could use ARC in my game's source code (converted using the Edit->Refactor->Convert To Arc menu option). I used this tutorial: http://www.tinytimgames.com/2011/07/22/cocos2d-and-arc/

However, if I try to actually include box2d into say, the HelloWorldLayer.mm, I get errors in b2Settings.h:
Lexical or Preprocessor Issue
'cassert' file not found

Can anyone please instruct me on how to get box2d working in a project like this? I'm willing to give physics collision a go, since I can think of other enhancements to my game I could use it for, but I can't do anything if I can't get the library working in the first place. Is there a static version of this library I could just add to Build Phases->Link Library With Binaries?

Thanks.

You say you don't need physics, but I would still use an engine to handle collisions for you as opposed to writing your own code. You'll save a lot of time.

Check out PhysicsEditor or SpriteHelper. They let you define polygon collision shapes in a GUI and export them to plists that you can read into your physics world. These shapes are very easily rotated in the physics world and synced up with graphics.

Re: scaling, I think there is a branch of box2d that supports it. If not, it'd be pretty easy to scale all the vertex coordinates relative to some center point and re-create the collision shape if needed.

What kind of compilation errors are you getting? Every place you use box2d needs to be in .mm since box2d is c++.

A Box2D Body is declared separate from a Sprite so it doesn't really know what you do to the Sprite unless you inform it. AFAIK, if it's not something within scope of CCSprite, then it won't get automatically affected by what you do with it, so unless you use the Sprite's rectangle for collision checking, don't expect any bounding shapes that you make to automatically follow the Sprite's properties.

If you scale a sprite, you'd have to destroy your shape and redefine it to the new size by applying the same scale modifier values as you did to your sprite to define the new shape. If you rotate a sprite, then you have to translate the body to have the same rotation (you will be constantly updating the body position to that of the sprite anyway, so adding the rotation isn't a big deal).

So in a sense it would be the same as you just declaring circles, and moving them and resizing them as the sprite is scaled/rotated. You can place the circle in a certain position relative to the position of the sprite using cos and sin functions on the sprite's rotation, then just have a multiplier for the radius of the circle for when you scale the sprite. If you want this to be automatic, then overload the CCSprite's setRotation and setScale/setScaleX/setScaleY methods to include the transformation to your bounding shapes.

I don't think it's fair to blame this on Cocos2D though...

Thanks for all the responses.

PDog, that is how you would check for collisions in a basic fashion, and it's the efficient solution I'm going for (I would recommend adding flags so that you can prevent checking for enemy vs enemy collisions, etc). Actually comparing circles for collision is the easy part. The challenge is how to define those collision circles/boxes. What if you have a sprite that has an irregular shape? You may want to use several circles. Not a problem in terms of checking for collision, but how do you set it? In code? That would be a huge pain if you have lots and lots of sprites. You'd also have to draw the collision spheres and rebuild every time you wanted to visualize changes you made to the collision for each sprite. This seems like it should be a common task, but I can't find a tool for defining collision boxes/circles anywhere.

Pterodactyl, pixel perfect collision is expensive, but more importantly unsuitable for many kinds of games. For example, I use a lot of bird enemies. Their wings shouldn't damage the player - just the main body. Likewise, if the player performs a kick, enemies that hit your back shouldn't be damaged.

IUridium, I tried to implement box2d last night, but I spent hours and couldn't get it to work. It just wouldn't compile for me. My project uses ARC, and I have the cocos2d project as an additional target in order to exclude it from ARC. Any time I tried to add box2d, whether through search user header files, or adding it directly to the project or whatever, I would get compiler errors. If I could actually get box2d to work, I would consider using it for collision even though it seems like overkill. What happens to a physics body if you scale or transform the sprite? Will the body follow suit?

Martin, the collision check itself is dead simple, but defining the circles is the problem. Additionally, you have to consider that the sprite may be transformed. For example, if I have a collision circle that is not in the center of the sprite, and that sprite is rotated/scaled, how can I get a workspace position and orientation for it? Collision bounds should follow the same transformations as the sprite.

Comparing two circles for collision is dead simple. Check if the distance of the centeres is smaller than the sum of both circles' radius. You can approximate a lot of shapes with several circles and put one big circle around it to optimize by pretesting the outer "bounding box circle". Rotating also is possible by rotating your circle center points around your object center.

Why you do not want to use Box2D for collision? It should work perfectly for what you need. Check these tutorials:
- http://www.raywenderlich.com/606/how-to-use-box2d-for-just-collision-detection-with-cocos2d-iphone
- http://www.iuridium.com/?p=548

Did you consider "Pixel perfect" collision detection?

Perhaps something like this: http://www.71squared.com/2010/03/collision-detection-methods/ may help?

Unfortunately, there doesn't really seem to be a way to efficiently create a bounding circle without using a series of rectangles.

Okay. I have a "runner" type game. Sometimes enemies appear to attack the player. Bound rects are inaccurate because my enemies aren't boxes, and they get screwed up by rotation actions anyway. I don't need any physics in my game. Is there ANYTHING AT ALL out there that I can use to define hitboxes and hurtboxes, preferably with circles, and use that data to check for collisions in my game? I so completely frustrated with cocos2d at this point, I'm ready to look at porting what I have over to Unity. I cannot stand to waste another entire day trying to get this library to configure properly with ARC and box2d (which I shouldn't even need to use for simple collision).