Precollision event sometimes has the incorrect side

[mattjennings]

Steps to Reproduce

https://codesandbox.io/s/compassionate-feynman-tqx8ok?file=/index.js

I'm noticing some odd behaviour in which collision with a wall on the right side sometimes returns a collision on the left. In the example above, use the arrow keys to walk into the wall and look at the console logs. The collisions are tracked by pushing the ev.side to an array during the precollision event. When walking into the wall, it will correctly have a collision on the right side. But if you stop moving, it will have collisions on the left side.

CleanShot.2022-08-28.at.17.02.30.mp4

Expected Result

Only bottom/right side should come through in precollision events

Actual Result

Left side comes through

Environment

• browsers and versions: Chrome 104
• operating system: macOS 12.5
• Excalibur versions: 0.27
• (anything else that may be relevant)

Current Workaround

This does not happen if you use an odd-numbered width player (say, 39px) and round the player's position in the postcollision event. (I have however noticed other odd behaviour when doing this, which I will make another issue for)

 constructor() {
    super({
      name: 'player',
      x: 200,
      y: 200,
      width: 39,
      height: 40,
      color: ex.Color.Red,
      collisionType: ex.CollisionType.Active,
    });

    this.on("precollision", (ev) => this.onPreCollision(ev));
    this.on("postcollision", (ev) => this.onPostCollision(ev));
  }

  onPostCollision(ev) {
		if (ev.side === ex.Side.Left) {
			this.pos.x = Math.floor(this.pos.x)
		} else if (ev.side === ex.Side.Right) {
			this.pos.x = Math.ceil(this.pos.x)
		}
	}

[mattjennings]

re: workaround leading to another issue, I'm not really sure it is an issue, so i'll just follow it up here.

If you have an odd-width collider and an anchor of (0.5,0.5), when you collide with a wall your collision is going to be resolved to a half-pixel. i.e 295.5 instead of 295. This makes sense. But if you round that position in the postcollision event, you are probably going to get unexpected results (for a collision on the right, you'll either move into the wall if you round up, or away from the wall if you round down). So I think the answer there is to not use an odd-width collider... but then that leads to this issue.

I'm not sure if you have any thoughts on that. I just happened to be using an odd-width collider in my game when I came across other issues, and switching to an even-width one lead to this.

[eonarheim]

@mattjennings thanks for the issue!

This is certainly an interesting issue, on first brush I'm wondering if the frame after resolution phase has an infinitesimal velocity towards the left, causing the next precollision to detect a possible collision with the left edge?

At minimum I think some floating point arithmetic edge case might explain the different behavior oddness vs evenness that you noticed

[eonarheim]

It looks like the (-0, -0) mtv vector is treated as the left side, I think this might be the source of the issue.

I think maybe filtering out 0 length penetrating collisions may resolve the issue?

[mattjennings]

Ah yes, filtering out -0 and 0 length collisions seems to do the trick!