playdate.geometry.lineSegment:fast_intersection(x1, y1, x2, y2, x3, y3, x4, y4)
For use in inner loops where speed is the priority.
Returns true if there is an intersection between the line segments defined by *(x1, y1)* , *(x2, y2)* and *(x3, y3)* , *(x4, y4)* . If there is an intersection, *x, y* values representing the intersection point are also returned.
But as it's not doing any math at all based on the line segment object you need to call it on, you shouldn't be required to call it on an object, and instead be able to call it via the class itself (apologies if i'm getting terminology wrong.) For example, this should work:
Not only that, if you do use the colon it'll throw an error. That's a typo that slipped in during some reformatting recently. Thanks for catching that!
I also am not sure if this is a bug or not, since I'm not sure of how edge cases should be handled, but I have two lines that have the same endpoint, and playdate.geometry.lineSegment.fast_intersection() returns "true" saying that they do intersect.
I'm not sure if the meaning of "intersect" in this case includes the endpoints, or if that's an undefined case, etc.
I'm not sure if this is one of the optimizations that this has over the regular lineSegment intersection routine.
sidenote; I do see like a 2.5x speed increase in using fast_intersection... which is awesome. I assume that the main differences are that it does the algorithm directly instead of referencing down through points and objects and other fiddly-bits.
Yeah, passing the values on the stack instead of shuffling them in and out of objects saves a lot of time! As far as whether meeting at endpoints is considered "intersecting".. I'd say yes, "intersecting" means there exists a point which is contained by both segments.
ok. I can throw together a couple of test examples that show the issues and border cases if that will help. (I'm working on a "Planarity" like game where i'm finding these. I might just throw together the test cases for my own reference anyway.
