This is amazing - v2.4.1, the latest version!
I haven’t yet played with it, but I’m guessing this doesn’t tie in with any of the built in Defold components? Ie, a world from the Box2D extension interacting with a world from a Defold collection proxy?
To tie game objects to a Box2D body, would you have to set the position manually? Would this lag a frame behind?
Sorry for the barrage of questions.
macOS Big Sur v11.4, tests passed.
It can’t work together with defold 2d physics.
You should remove defold engine box2d in appmanifest.
So this extension can’t interacting with defold components.
All physics you set manualy in code.
Yes.
You get position from body.
Then set position to go.
go.set_position(body:GetPosition())
About frame lag.
This topic?
Dealing with the one frame lag when visualising dynamic bodies - #6 by Mathias_Westerdahl
if i understand correctly problem happened because script update is called before physics update?
In this extenstion you update physics manualy in script.
function update(self, dt)
self.world:Step(1 / 60, 8, 3)
self.world:DebugDraw()
end
Also you always get actual possition by body:GetPosition()
That’s brilliant! Great to have direct access to the step function.
Thanks.
All platforms worked 
Great job!
I believe that once an asset is updated in the “awsome-assets” repo, it should trigger a rebuild of the static webpage which is defold.com.
Ofc, sometimes we accidentally change something that makes it not build.
I think we’ll ping @britzl and I think he might have an idea what’s up.
Thanks. I’ll check why it doesn’t show up!
Thanks:)
I’ve released a new version 0.85
function box2d.InitializePrismaticJointDef(bodyA, bodyB, anchor, axis) end
Released a new version 0.89
Adding new usefull functions. 
On next release will add binding for b2Manifold. After that ne will have all basic functionality.
[CHANGE LOG]
1)add world:RayCast
--- Ray-cast the world for all fixtures in the path of the ray. Your callback
--- controls whether you get the closest point, any point, or n-points.
--- The ray-cast ignores shapes that contain the starting point.
--- @param callback function(Box2dFixture fixture, vector3 point, vector3 normal, float fraction)
--- @param point1 vector3 ray starting point
--- @param point2 vector3 ray ending point
function Box2dWorld:RayCast(callback, point1, point2) end
2)add world:QueryAABB
--- Query the world for all fixtures that potentially overlap the
--- provided AABB.
---@param callback function(Box2dFixture fixture)
---@param aabb table the query box. {lowerBound = vmath.vector3(0), upperBound = vmath.vector3(0)}
function Box2dWorld:QueryAABB(callback, aabb) end
3)add world:SetContactListener
no old_manifold in PreSolve
no impulse in PostSolve
--- Register a contact event listener.
--- listener = {
--- BeginContact = function (contact) end,
--- EndContact = function(contact) end,
--- PreSolve = function(contact, old_manifold) end,
--- PostSolve = function(contact,impulse) end
--- }
---@param listener table|nil
function Box2dWorld:SetContactListener(listener) end
4)add binding for b2Contact.
18 functions
Released a new version 0.9
Now extension contains all basic functional.
It ready for using in real projects.
Next step is testing it on real projects.
I will try to make some small games, after finish my current game.
Any review, feedback and using are welcome:)
1)add Box2dContact:GetManifold()
--- Get the local manifold.
---@return Box2dManifold
function Box2dContact:GetManifold() end
2)add Box2dContact:GetWorldManifold()
--- Get the world manifold.
---@return Box2dWorldManifold
function Box2dContact:GetWorldManifold() end
3)move all native code to namespace box2dDefoldNE
Fantastic. You’re a hero.
I finally decided to shirk my real work and try this out.
Fortunately I’ve got a pretty good idea how Box2D works from using Love2D, but wading through the documentation is still a bit painful. Your example project is very helpful to have. I might submit a PR later to make the documentation more pretty and possibly split it up into multiple documents, if you’re open to that?
Question 1:
Would it be a pain to shorten the names of the constants? Or are you committed to having the C+±style prefixes on everything?
It’s pretty annoying to type: “box2d.b2BodyType.b2_dynamicBody” every time (not to mention it’s hard to read.)
I would prefer: “box2d.BodyType.dynamic”, or maybe: “box2d.TYPE_DYNAMIC” to make it fit with the Defold API and the naming conventions for constants that I’m familiar with.
And all the others, like:
box2d.b2Shape.e_circle → box2d.SHAPE_CIRCLE
box2d.b2Draw.e_shapeBit → box2d.DRAW_SHAPE_BIT
[Edit] Maybe even shorten the common ones more, since there’s no overlap, i.e: box2d.CIRCLE, box2d.DYNAMIC
Of course the end user can always make their own aliases, so it’s not a huge deal.
Question 2:
I think I know this one, but just to check: All the units for making shapes and body positions are in Box2D “meters” right? And the physics_scale for the debug draw is only to scale the drawing?
Question 3:
Can the velocity iterations and position iterations for Box2dWorld:Step() have default values? I imagine 99% of users will just use the recommended values of 8 and 3 (but they’ll have to look them up too).
Thanks for your feedback:)
About documentation:
Yes i am open)
Documentation is very big, and painful.
2155 lines in raw edit=)
It was fast to make it. And
it is better than no documentation.
Github have support for wiki pages.
Most of documentation must be there,
not in readme))
For now, the best documentation is box2d documentation)) It is splitted, and contains a lot of explanations and examples)
About example:
Box2d have good testbed app;
https://box2d.org/documentation/md__d_1__git_hub_box2d_docs_testbed.html
I want to make example scene same as it.
It contains a lot of example scenes, and some helping ui.