[flame_forge2d] Body component still renders in original position when setting transform to Vector2(0, 0)

[JankLai]

What happened?

The body_component's setTransform method appears to have a bug when called with Vector2(0, 0). While the component's position property is correctly updated to Vector2(0, 0), the component is still rendered at its original position on the screen. This suggests a rendering issue where the visual representation of the component is not updating correctly despite the underlying position data being modified.

What do you expect?

When setTransform(Vector2(0, 0)) is called on a BodyComponent, it should visually move and render at Vector2(0, 0). The rendered position should reflect the updated position property.

How can we reproduce this?

1. Create a BodyComponent within a FlameGame that is using Forge2DWorld.
2. Initialize the BodyComponent at a position other than Vector2(0, 0).
3. Call setTransform(Vector2(0, 0)) on the BodyComponent.
4. Observe via debugging or printing the component.position that it is indeed Vector2(0, 0).
5. Observe that the component is still rendered at its initial, pre-setTransform position, and not at the origin Vector2(0, 0).

What steps should take to fix this?

No response

Do have an example of where the bug occurs?

No response

Relevant log output

Execute in a terminal and put output into the code block below

[√] Flutter (Channel beta, 3.28.0-0.1.pre, on Microsoft Windows [版本 10.0.26100.2894], locale zh-CN)
[√] Windows Version (11 专业版 64-bit, 24H2, 2009)
[√] Android toolchain - develop for Android devices (Android SDK version 35.0.0)
[√] Chrome - develop for the web
[√] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.10.1)
[√] Android Studio (version 2022.1)
[√] VS Code (version 1.97.1)
[√] Connected device (3 available)
! Device emulator-5562 is offline.
[√] Network resources

Affected platforms

All

Other information

Upon inspecting the source code, it is suspected that the issue might originate from the renderTree method within the body_component. Specifically, the conditional statement:

if (matrix.m14 != body.position.x || matrix.m24 != body.position.y || _lastAngle != angle)

appears to be problematic. It is observed that matrix.m14 and matrix.m24 are consistently 0.

I am not very familiar with Matrix4, so this analysis is purely based on observation and is just a guess. The issue seems to be resolved by modifying this condition to compare matrix.m41 and matrix.m42 instead

Are you interested in working on a PR for this?

• I want to work on this

[spydon]

That's curious, I thought m14 and m24 would represent the current x and y, which is why that if is there - to ensure that the calculation isn't done when not needed.

When looking here:
https://github.com/flame-engine/flame/blob/main/packages/flame/lib/src/game/transform2d.dart#L172-L173

It seems like m14 and m24 (same as [12] and [13]) shouldn't be zero if the previous value wasn't 0, so I wonder what is happening here...

Ah, or is the whole situation described above happening in the same tick?

[JankLai]

That's curious, I thought m14 and m24 would represent the current x and y, which is why that if is there - to ensure that the calculation isn't done when not needed.

When looking here: https://github.com/flame-engine/flame/blob/main/packages/flame/lib/src/game/transform2d.dart#L172-L173

It seems like m14 and m24 (same as [12] and [13]) shouldn't be zero if the previous value wasn't 0, so I wonder what is happening here...

Ah, or is the whole situation described above happening in the same tick?

No, what I described didn't happen in the same tick. Check out this video to see the problem(As you can see I called the setTransfrom with Vector2.zero when chapter updates). And maybe [12] is m41 instead of m14?

transform_issue.mp4

[spydon]

And maybe [12] is m41 instead of m14?

You're absolutely correct!
It should be m41 and m42.

Do you want to provide a PR with the fix?

[JankLai]

@spydon Thank you for your quick response and for confirming my guess!

To be honest, I'm not familiar with the code logic in this specific area, and I'm concerned that I might miss something important if I were to attempt a fix. Additionally, I'm currently focused on my personal project and have limited availability.

Thank you again for your understanding.

[spydon]

@spydon Thank you for your quick response and for confirming my guess!

To be honest, I'm not familiar with the code logic in this specific area, and I'm concerned that I might miss something important if I were to attempt a fix. Additionally, I'm currently focused on my personal project and have limited availability.

Thank you again for your understanding.

Alright, no problem, I'll do the fix myself tomorrow. :)