After that, I run the program and it’s not compile. It failed with 2 errors:
Apple Mach-O Linker (ld) Error Group
"B2DebugDrawLayer::create(b2World*, float)", referenced from:
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I tested another GLES-Render classes and some compiles work fine but I don’t view the 4 box line that box2d is drawing. Anyone have any example that works in the last versions? Adding the layer child should be sufficient ? or I should be edit other part of my code?
And in the method that I create the gameScene and world, I added this lines:
DebugLayer *debugLayer = new DebugLayer(world);
When I compile the game I see the drawings but these are in another place, not exactly where the sprites are. Do you understand me? For example, if I have a sprite box in the middle of the screen, I view this draw box not inside the sprite box, else in another part of the screen. How can I view the draws exactly where sprites are?
If the debug drawing doesn’t coincide with the sprite positions then you are calculating it differently in two places.
You must calculate a sprite’s position from the box2d position, and that involves some sort of scaling (box2d works in meters, your screen works in pixels - so something like 32 pixels per meter must be set, somewhere)
If you use a different number (or offset, if one is used) in the sprite positioning vs the debug draw, then that will cause the debug to be drawn elsewhere compared to the sprite.
I don’t have time to look in detail right now, but try this:
Set your box2d object in a fixed position using no multiplier - e.g. set it to (10,10)
Work out what your sprite position should be from this
e.g. 10 * multiplier, 10 * multiplier
Don’t update anything, just display that.
Look where your sprite is and look where your box2d debug is
Remember, the box2d debug is using a calculation to convert its location in meters to pixels, and you need to do the same calculation for your sprite.
Also, don’t worry about the size of the sprite for now!
Once you have worked out what multiplier you are going to use (32 or 64 are the normal values) everything should fall into place!
But the overall rule is to let the box2d position determine the sprite’s position on screen, and not the other way around!
@Maxxx thanks for the answer!
I forgot change this line: _debugDraw = new GLESDebugDraw(32); to 50 (my SCALE_RATIO is 50).
However, I continue having problems.
In many sprites I changed the default AnchorPoint (the default is Vec2(0.5, 0.5) and I changed it to Vec2(0, 1). I detected that if the sprite uses the default anchor point, it works fine. But if not, the sprite and the box2d draw is in different places. It sounds like the box2d draw class always assumes that that the anchor point is 0.5, 0.5.
Is it a bug? I think that the box2d draw should be drawn in base to sprite anchor point setted. But I have no idea what we should edit for fix this bug. GLES-Render.cpp? DebugLayer.cpp?
First: No it is not a bug.
Box2d is a physics simulator - if you choose to use it to provide a graphical representation using sprites then it is up to you to position the sprites where the physics engine says they are.
The physics engine says a box with side of 1m is at (30,20) in the physics world, then it is up to you to place your sprite in a suitable screen position for display.
Box2d provides a debug draw to help you debug. It is obviously convenient for you to draw your sprites in the same place that box2d draws its debug representation of the world.
If you choose not to (which you are by setting your anchor point to (0,1) then that won’t work!
The question is, why are you choosing to set your anchor point differently?
When using a physics engine you really should be coding “physics first” - so set up your model in Box2d then position your sprites accordingly - so leaving the anchor point at (0.5,0.5) makes this approximately 30,000,000 times easier!!!
If you have a non-central offset then you will need to calculate the position of the sprite based upon its dimensions, converted to meters - which is one heck of an overhead!!!
I’m choosing to set the anchor point differently for convenience. If coco2d provides this method I think that is for use it . I could adapt my sprites to the default anchor point. Reading your answer I think that I have not another alternative
Lots of people start with physics engines the same as you have - by positioning the images first then trying to use physics.
Doing it physics-only means the anchor point is no more or less convenient as everything will be positioned according to the physics