CollisionFrontEnd

[Geokureli]

PR, here: #3431

Spinoff from #3418

FlxObject.separate is weirdly laid out and could use a redo.

Operations like computeOverlapX should just compute the overlap, and not set touching flags. We can refactor this system completely and avoid breaking backwards compatibility if we move all of this to FlxG.collision.

I think FlxG.collision.separate should:

1. Check whether the swept hulls overlap (once, not per axis)
2. Compute the overlap of each axis
3. Separate on the smaller axis before the other, setting touching flags when separating, not when computing overlap

[MondayHopscotch]

I think point 3 will have other implications on backwards compatibility with how FlxTilemaps currently work. The current implementation of doing the axes in a fixed order results in tilemaps being very forgiving as far as tiles' allowCollisions is concerned.

Namely, having the tiles all set to allowCollisions = ALL works fine in this scenario (moving character in blue, tilemap in orange):

As the player approaches the seams between tiles, it doesn't matter which axis is resolved first as long as it's consistent.

With the 'smaller axis first' resolution, having proper allowCollisions on the tiles becomes critical as this scenario:

The outcome depends on which order the tile collisions are resolved. if the left ground tile is resolved first, the player snags (as the x-overlap is the smallest axis). If the right ground tile is resolved first, they do not snag.

I only bring this up as FlxTilemap doesn't try to do any smart collisions adjustments based on tile adjacency (at least not that I have spotted). It feels like the current implementation is better in the AABB world that flixel currently lives in due to simplicity and compatibility. I'm not fully against moving toward more of a SAT approach, but we may want to just collect other things that will be impacted by moving to that style of resolution.

---

I know autoTile + proper tile properties makes this a non-issue (when used properly), but I would assume most people aren't using these features. I know I historically haven't.

[Geokureli]

I know autoTile + proper tile properties makes this a non-issue (when used properly), but I would assume most people aren't using these features. I know I historically haven't.

Agreed, it's pretty much assumed that nearly all tilemaps will have all solid tiles' allowCollisions of ANY, any system that cannot handle this is not fit for release.

This ended up only taking a couple hours, it suffers from the issue I just mentioned, but I have an idea. I'm not completely sold on the new collision method, even if my fix works, but it will be faster than checking all tiles for X and Y separately, and I have other ideas