I did some test and I saw when an object have a high velocity/speed the collision don't trigger.
On the Flame docs it notes:
Do note that the built-in collision detection system does not take collisions between two hitboxes that overshoot each other into account, this could happen when they either move too fast or update being called with a large delta time (for example if your app is not in the foreground). This behaviour is called tunneling, if you want to read more about it. I would love to see something talking about that and how we can avoid that!There is a good approach for that type of thing?
I realize something with some other test.
If angle are modified, it will trigger the collision. (I don't know why it won't whiteout that)
The update function (that modify the Y value) look like that:
@override
void update(double dt) {
super.update(dt);
y = y + _speedY * dt - _GRAVITY * dt * dt / 2;
_speedY += _GRAVITY * dt;
angle = velocityAngle(_speedY);
}
Example:
On that gif you can see the cube have a shape (HitboxRectangle) and the green floor too. But collider don't trigger. Only trigger if I "Jump" on the hitbox.
P.S. the laggy visual/animation is only because its a gif
EDIT: I realize something with some other test.
If angle are modified, have a better chance to trigger the collision. Looks like it simply works now. (I don't know why)
Imagine you got a function that return an angle base on your true current angle on the update and you add a randomise number to add on micro variation on your current angle.
The angle randomiser is so small that is not even visible. (At least on a canvas square)
...
var rng = (new Random().nextInt(4) - 2) / 1000;
return angle + rng;
I don't really like that weird solution.. but it works! Maybe it could helps to discover the why and a better solution.