Issue with player bounding box and collision detection

[Vay]

My stairs are 16x16, and my Player's bottom pixels are also on line 16 as you can see, but this is as close I can possibly get to the stairs without them warping me: https://i.imgur.com/lRjfdyz.png

If I go down one more pixel, my 16x16 Player is still not colliding with the 16x16 stairs, it is just adjacent to them, yet this triggers the collision still. The collision detecting is off by 1 pixel up, and 1 pixel left. You can test this by making a 16x16 blank square as a player, and creating a solid 16x16 block, and seeing how close you can get to the block on all sides.

This affects things like placing a Player with a bounding box that borders the bottom of the Player sprite one tile above a 16x16 staircase that warps, as the 1 pixel offset collision detection will detect it, and warp you right back down again. Any fixes for this?

Edit: Same applies to monsters with a bounding box that borders the bottom of the sprite, and then placing the monster directly above a solid block tile, the collision detection will trigger and the monster will be unable to move as it believes it is inside the solid block now. Suggestion for now is to have a bounding box that is 1 pixel in from the side on all sides of a monster or player.


Edit 2: I'm beginning to notice some of the issues I've had I believe is due to this bug in question. Here's another instances where I believe the 'Warp To Screen' tile is incorrectly colliding with a 'Solid' tile because it is above it, which messes something up and allows my slime to slide over a 'Solid' tile.

https://i.imgur.com/nu9KK6B.png

 

[RadJunk]

This collision detection is sort of vanilla, optimized for space and speed. There is a potential issue with this.

Here is how it works:

1) Check top left...if zero, do other checks. If not, *HANDLE COLLISION WITH THAT TYPE* (forget other collision points)
2) Check top right...if zero, do other checks. If not, *HANDLE COLLISION WITH THAT TYPE* (forget other collision points)
3) Check bottom right...if zero, do other checks. If not, *HANDLE COLLISION WITH THAT TYPE* (forget other collision points)
4) Check bottom left...if zero, do other checks. If not, *HANDLE COLLISION WITH THAT TYPE* (forget other collision points)

You'll see, this COULD lead to issues if, say, it reads a warp type at the top left...it'll never continue the reads to see if any of the other points see a solid.

It's not really a *bug*, it's just a code that may work for certain instances fine, and give trouble in others. As weeks go on, we'll introduce different codes, users will start making their own codes for things, etc. This is a relatively easy one to fix, but the solution adds up to 4x the cycles per frame (quicker to arrive at that classic NES slow down), so that becomes the caveat.