Rotation Order
I think the basis has been implemented for the rotation to finally work.
The clue here is that I first check if the rotation can be applied.
When there is no collision in that case, we apply the rotation and use those points and edges to do the normal collision checking.
At that point the code just works, as we’ve seen previously.
I was afraid this approach wouldn’t be convincing. Though it turns out it’s totally fine. And the entity can keep it’s angular velocity as well. So once it doesn’t hit a wall anymore it will start rotating again.
The idea to switch the order of checking for rotation came from TRS. TRS stands for Translate, Rotate and Scale. It is the order in which you would do these transformation on a matrix. Though you need to read it from right to left. So first scale the object, then rotate and then move it to the desired location. That’s exactly how the collision code now works.
Tile Regions
As I said, the collision works like normal once the rotation has been applied.
I fixed this previously by fixing a bug in the tile region code.
However, I noticed another bug in there.
I was actually picking the wrong maximum values.
The code was checking for the minimum instead of the maximum.
I found this issue while trying to solve a new mystery. Spoiler alert, the bug fix doesn’t fix this mystery problem. What happens is that when moving along a diagonal wall, the entity seems to hit something at the edge of two diagonal tiles. This behaviour is very familiar as the exact same happened with the previous bug I mentioned above. That’s why I thought it was the tile region again, not taking into account the rotation correctly.
Turns out the tile region, with the new bug fix, is finally working as it should. So that’s why I have a new mystery to solve.