That will work, assuming the player fits in one pixel.
@EliasHasle
Well, we know position of the player and the width of its sprite, so we need to check two points instead of one.
TBH, we know nothing about what and how @Aerion does, so we can say whatever we want and share the craziest ideas we have, and in the end none of it will be relevant to the real things in the project
Which two points would that be? How about all the other points that the sprite or sprite base intersects?
That’s right. It would be useful to have some more specific questions, visual examples, code samples and running examples.
Also good question. I’m out of ideas
One may check multiple (all) pixels along a straight line in the direction of motion, from distance 0 to spriteBaseWidth/2. Or even only the farthest one. Still not perfect collision detection, though, since the sprite has a width that is swept along the motion.
One may also check all pixels within the sprite area, but that can become prohibitively expensive, and is inherently wasteful.
Just another mad thought: somehow to provide coordinates of a restrictive polygon on a tile (the area where the player can’t step on, in UV coordinates for example) and check for intersection of it with a line segment, formed with two points of sprite’s base. In case of intersection, means that the player is on the restricted area and needs to be set to the previous position. Or do it preventively, before the real move of the player’s sprite.
That’s not a mad thought at all. If the polygon is convex, you can also apply an SAT-based intersection test using a polygon for the player sprite base.
Can we please stay on the topic at hand & not hijack my thread? Thank you
Please declare (or rename?) the topic, then. I think both @prisoner849 and I thought we were on-topic, trying to help you here.
My apologies. I misunderstood.