Defold 1.10.0 BETA

[Epitaph64]

Thanks for the fast response! Things are working well now.

[totebo]

@Mathias_Westerdahl

Edit: Reading his code a few times, I guess that the component’s body doesn’t register immediately.
Not sue why that is though. If it’s a Box2D thing

Native Box2D functions are all synchronous, so that’s unlikely to be the culprit.

[denis.smirnov.by]

@Mathias_Westerdahl

Not sure what he’s referring to

I just want to say that this mini project behaves differently in 1.9.8 and 1.10.0.
phy_test_box2d.zip (2.4 KB)

[aglitchman]

@Mathias_Westerdahl

Not sure what he’s referring to. Setting the linear velocity is a synchronous function call.

Edit: Reading his code a few times, I guess that the component’s body doesn’t register immediately.
Not sue why that is though. If it’s a Box2D thing, I’m not sure we want to add extra code to handle it, as we generally want to avoid making custom changes to the Box2D code.

I tried to analyse the difference between the two versions of Box2D and it turns out that setting the linear velocity (and other params) in Box2D 3.0 requires that the body must be in the physical world and not sleeping (in legacy version it was not required). And it seems that when creating a body with the NewCollisionObject2D function this condition should be satisfied, but for some reason it is not.

By setting the enabled flag (in Defold it is called active) the body can be forced to be placed in the world and wake up. So this code works the same in both versions:

	local body = b2d.get_body(url)
	print("is active: ", b2d.body.is_active(body))
	b2d.body.set_active(body, true)
	print("get velocity (1): ", b2d.body.get_linear_velocity(body))
	b2d.body.set_linear_velocity(body, vmath.vector3(0, 10, 0))
	print("get velocity (2): ", b2d.body.get_linear_velocity(body))

-- DEBUG:SCRIPT: is active: 	false
-- DEBUG:SCRIPT: get velocity (1): 	vmath.vector3(0, 0, 0)
-- DEBUG:SCRIPT: get velocity (2): 	vmath.vector3(0, 9.9999990463257, 0)

But it seems to me that the body is supposed to be enabled (active) by default…? Not sure, I never used the b2d api. We were happy with the “old” physics api, where settinglinear_velocity property with go.set enables the body, then sets the velocity - there is no difference for us in the behavior.

[Mathias_Westerdahl]

Thanks for helping out investigating Artsiom!
As the factory.create() is a Defold function, and the expectation is that the body is active, I think we should enable the body by default.

We were happy with the “old” physics api,

While I can appreciate that, it’s just an immense burden to support, as the idea was to support all backends (and as we all know, they all act differently)
Once our physics backends are fully made into extensions, we can deprecate our “physics api”, in favor of the specific Lua bindings for e.g. Box2d.

[Mathias_Westerdahl]

As the factory.create() is a Defold function, and the expectation is that the body is active, I think we should enable the body by default.

Comparing it with the old Box2d v2 version, those bodies are also not active after being created.
The main difference is in how the actual setlinearvelocity() function behaves between the versions.
And, as such, I’m now more inclined to leave it as-is, and defer to the new Box2D documentation.

But it seems to me that the body is supposed to be enabled (active) by default…?

I’m not sure we had a design decision for that particular flag back then (15 years ago)
But nowadays we try to be backwards compatible to a reasonable extent, or try to be as “vanilla” as possible, so we don’t have to maintain a lot of workarounds.

[aglitchman]

@Mathias_Westerdahl

I’m now more inclined to leave it as-is, and defer to the new Box2D documentation.

I agree

About our game Puffy Cat: in Box2D 3.0 something has been improved in the implementation of joints, as @notbadgun has removed our ‘hacks’ for legacy Box2D and as the result the soft body works as before. Great!

One thing that got worse: it’s the interaction between kinematic and dynamic bodies. We have platforms implemented through kinematic, which we move through position changes. And this leads to undefined behaviour of dynamic bodies. On legacy Box2D everything works ok, it manages to handle this, but on Box2D 3.0 unfortunately dynamic bodies go crazy. In short, this is the feature request that needs to be made that we can fully transition to the new Box2D: Physics 2D: moving a kinematic object with linear_velocity and angular_velocity · Issue #10446 · defold/defold · GitHub

[AGulev]

We have a very custom solver in our old Box2D (I think we use one from Bullet3D or something like that), which is much more stable in such cases. I remember experimenting with it and trying to use the default solver, and the result was less stable in exactly such cases.

[totebo]

@aglitchman

In short, this is the feature request that needs to be made that we can fully transition to the new Box2D: Physics 2D: moving a kinematic object with linear_velocity and angular_velocity · Issue #10446 · defold/defold · GitHub

I would also like to see this functionality. I submitted a GitHub issue about it in 2023, but the issue was closed, probably because set_linear_velocity() and set_angular_velocity() were added. However, these functions don’t actually move kinematic bodies, which was the original request:

Support for moving a kinematic object with linear_velocity and angular_velocity

[Epitaph64]

I’m trying to get my game working properly using the new version, but I’m running into a couple of breaking issues. The first is that item drops in my game slowly move around after dropping and setting velocity to 0 doesn’t stop this. Also, enemies with larger hitboxes have bad collision handling often teleporting through walls and other enemies. Neither of these issues affects the game in 1.9.8. Anyone have any ideas how to fix it for 1.10.0? This may be the same issue as Defold 1.10.0 BETA - #68 by aglitchman reported.

EDIT: Another oddity I noticed is that if handling a hash(“collision_response”), if you delete the entity with go.delete this event can fire again even though the entity should be gone. Adding an extra boolean to track the logic I want to occur only once fixes this. However, I had to track down a couple places where I had built the game with the assumption that it shouldn’t fire again if go.delete is called.

[britzl]

@Epitaph64

EDIT: Another oddity I noticed is that if handling a hash(“collision_response”), if you delete the entity with go.delete this event can fire again even though the entity should be gone

Reported as collision_response events can fire multiple times · Issue #10447 · defold/defold · GitHub

[britzl]

@aglitchman

On my test device on Box2D 3.0 I see performance 2 times lower than on legacy Box2D, i.e. 25 fps vs 12 fps.

Reported as Box2d performance regression between Box2d v2 and Box2d v3 · Issue #10448 · defold/defold · GitHub

[britzl]

@jhonny.goransson

Box2D Version 3

This release includes an updated version of Box2D to the latest version 3. While the integration has been built on top of the same data formats as before and should largely behave the same, please be aware that projects can potentially behave slightly differently now. According to the documentation, the new Box2D version is more or less a full rewrite of the physics engine, which means that some settings might need to be tweaked.

The old version is considered deprecated, but if you want to change to the old version you can change this by using an app manifest. To read more about app manifests, please have a look at the app manifest documentation.

We have made the decision to switch back to Box2D 2.2.1 (the version used in Defold up until now) as the default for Defold 1.10.0 and keep the new Box2D 3.0 version as opt-in via an app manifest.

This will allow us to focus on other beta issues and release 1.10.0 later this week. We will then proceed to look into the discovered Box2D 3.0 issues reported here (thanks to everyone who tested and reported issues!) and hopefully switch to Box2D 3.0 for the next release instead.

[Visionaire]

Testing this version.

I also see a bit of order in the design of the forum page, they are taking things seriously on Defold! Thanks for everything!

PD. This is not the topic, somehow I had to express it to you.