So your level physics basically trace the boundary of the contiguous tiles. When you do that with the entire level, you end up with something like. You don't want that the vertical edges between them to affect the player's movement.

So, if you have have two adjacent tiles, like so. For each tile, I would see which sides of it are touching another tile. I've solved this in the past by processing the tiles to track which of their edges are 'live'. However, if the sprite intersects another tile horizontally, by less depth than the Y-axis, the resolution's direction will be horizontal and the sprite will be pushed to the corner. I don't recommend this solution, it took me 1 year to get all the details right. But this solution doesn't allow to get 'sliding for free', as with the others you have to model sliding on top of a surface as a resolution of the contact. With that vector, and some tricky math you can sort the collisions out, and get which ones really occur before. It requires to take into account the 'previous position' of the player, so you can have its 'frame displacement vector'. The 'correct' solution, with no tricks, is a bit more complex, and requires more math. You can probably have this done in 1 evening. This will give you no trouble with the walls or the ground, and it's the one I recommend. The distance you have to 'remove' is proportional to the max speed of your player and the max dt. This basically sidesteps the problematic areas of your current problem by 'removing' the troublesome parts of your player (the corners). You can have this done in hours.Īn intermediate solution is not using a box for your player instead, you use a 'cross' made of two boxes one for the 'head and feet', which responds to vertical collisions only, and the other one for the 'arms', which responds to horizontal collisions only. It will still occasionally loose vertical velocity when falling next to a wall, but that's much less noticeable. This will make your player 'slide' correctly over floors. The typical way people resolve this is by doing first Y-based resolution, and then X-based. The player 'tends to get trapped on the seams' because depending on the timeframe, the minimum displacement vector will be sideways instead of upwards. It typically fails when modelling a player moving on top of a row of cells. The minimum displacement vector isn't always the intuitive solution. The distance is equal to how deeply the hitbox has penetrated the other, and the direction is determined by checking which depth is shorter - horizontal or vertical. I've looked high and low on the Internet and haven't found too much on the way of this problem. I feel like there's some very simple thing I missing, because games from the 80s running on far less power than mine have managed to solve this problem elegantly. Here's another diagram showing just that problem, and what I'd like to happen. Sprites don't fall that quickly, so they rarely drop too deeply into the tiles' hitboxes, ensuring that the Y-axis is the shorter of the two. If a sprite collides with two tiles at once, there are two collisions to resolve. The problem is resolving multiple collisions. ( ) a quick diagram I made showing such a resolution.

The resolution direction will be in the direction of the shorter depth.

Resolving single collisions is just as easy - one just needs a distance and a direction. If true for both axes, then the hitboxes are colliding. (Yes, this is probably a bad idea.) The level uses the Quadtree model to provide spatial partitioning.ĭetermining if two hitboxes are colliding is easy - for each axis, check if part or all of the first hitbox is between the edges of the second. My level is comprised of tiles that are NOT aligned to a grid - they can be placed freely in a level, can overlap, and can be of any rectangular size. These hitboxes are Axis-Aligned Bounding Boxes, and each sprite and tile has one. The two objects I use for collision are sprites (objects that have position, velocity, acceleration, and a hitbox) and tiles (fixed objects that have position and a hitbox). I'm working on a platformer game that uses tile-based collision detection.

Vector 2d collision