LÖVE

But (t==t) is always true.

@pgimeno it's not pickiness xD , it's an important pointer.

That point-slope code has special cases for when the player and enemy are perfectly aligned on the X or Y axes (so this prevents a division by zero, or when the slope 'm' results in zero itself), but for the case you mentioned of the player being at/beyond the screen borders, I think you could solve it by making the intersection point the player's position already.

So when the player is at or beyond the screen edges, the arrow position should equal that of the player's. But this shouldn't happen in practice I think -- a game like Super Smash Brothers that has this kind of feature seems to consider the ray origin as the center of the screen. Here you can see that magnifying glass bubble for when a character is off-screen:

darkfrei wrote: ↑Sat Jan 09, 2021 8:55 pm But (t==t) is always true.

Not for NaN values; those are the only ones where x==x is false.

what does NaN mean ?
By the way, with that whole t==t thing I did my own rough fix through trail and error before pgmeno posted his fix when I saw things getting buggy.

NaN means Not a Number. You get those in a few situations; dividing 0/0 is probably the most common. Checking for NaN with t == t saves adding guards for division by zero in my code. The case nonzero/0 gives infinity, and that is already handled properly because it won't pass the test for being the smallest.