Ray Logic - Corner Cases #2
Description
When rays hit corners, they sometimes behave perfectly; other times they will "escape" through that corner. Give it a shot to see what I mean.
I believe this may be happening because of the way that rays judge whether they've collided with something. When a ray "checks" all the walls (really this checking happens in a function which is a member of class battlestate) the game iterates through the walls until it finds one the ray's front-most segment is intersecting with, and then has it collide with that one appropriately.
What it doesn't do is continue checking all the walls after it finds a collision. This means that if a ray moves forward and suddenly intersects with two walls (which happens at corners a lot!), it still only collides with one. And of course it should only collide with one--the problem is how it chooses WHICH one to collide with. The current setup would make it so that it simply collides with whichever wall has the prior index, which is probably why the bugged collisions seem to only happen around 50% of the time (barring cases where the reflective_bisector function is invoked).
If this is the case, fixing the bug would entail updating the "check for collisions" algorithm in class battlestate, so that it considers EVERY segment intersecting with the ray's front segment, sorts those collisions by proximity to the tail end of the ray's front segment, and then proceeds to call ray::bounce only on the segment which is closest to the tail end of the ray's front segment (or, equivalently, furthest from the the ray's head).
Fixing this bug, if I'm correct about what's causing it, begins in battle.h at line 196 (master branch)
P.S. It is possible that fixing this bug could cause the "reflective bisector" function to become obsolete. And as much fun as I had writing that function, I'd be fine with scrapping it if need be. It presently (purposefully) forces rays to pass through walls when near corners so that they hit the invisible bisector segment instead. This has the potential to lead to unwanted results. When checking whether a solution to the aforementioned bug is working as intended, consider disarming the if-statements that detect proximity to a corner and then invoke the bisector band-aid fix if the collision is "at a corner". It should be sufficient to make it so the if-statement at line 269 never evaluates to TRUE whilst trying to fix this bug (and after, if it turns out to be as easily fixable as I think it just might be).