I think the collision judgment is not correct.

I tried to write this topic in a bug report, but I didn't post it because construct3 might have a reason to do this.

This is a simple example, so I did not attach a link to the example project.

===================================================

Let's say you have two boxes of size 32x32.

One is Solid (0, 0).

The other is an 8direction (player) located at (32, 64).

Now if you move the player up, it should finally be at (32, 0).

However, the player stops at (32, 32).

This is because we believe the game engine has collided with Solid.

Since it doesn't collide visually, this can be thought of as a bug from the player's point of view.

Of course, game developers can circumvent this, but in this case it's not good for game developer UX.

I don't know the engine's internal logic, but suppose the x coordinate of Solid's last point (32, 32) is A.

Suppose the starting x coordinate of the player is B.

I now assume that the engine logic is IF (A> = B) IS COLLISION.

I think this should be IF (A> B) IS COLLISION.

===================================================

Should I see this as a bug?

Or maybe there's an internal reason for optimizing OBB or polygon collision logic, so should I just use it?

You should make an example, but I think your understanding of the collision polygon, and hotspots may be the issue.

OK. Example link.

The project looks like it is working normally. There doesn't seem to be anything obviously wrong with it.

FYI we can't make even subtle changes to something so important as to how collisions are detected. It would break thousands of projects and result in loads of angry customers. So then we'd be forced to put it back to how it was, and everyone would trust us a little less. Backwards compatibility is hard.

I think the player should come right next to Solid when press the up arrow to move.

Like ■□...

Anyway, many users didn't think this was weird. I think you are normal too.

It's still weird for me... But it's OK.

Thank you.