atan2(1,0x8000.0001) returns 0.25, as expected. However atan2(1,0x8000.0000) returns 0.75.

This is the kind of stuff that could be compiler-specific because 0x80000000 is a bit special, however I get this on both Windows and Linux (64-bit).

You really shouldn't expect a specific result here. Technically, 0x8000.0000 is ±32768, kinda like 0 is technically ±0. For convention's sake we assign it to -32768, but it's called "the weird number" for a reason, since it's technically got an ambivalent sign, just like 0 does. If you negate it, it doesn't change, just like 0.

You should always treat it as garbage-in and avoid ever letting any real-world/useful values become it. Keep your range to ±32767 and you'll be happier.

Sure, I know all that. But technically 0x8000.0000 is -32768, not ±32768. It behaves like -32768 with 2’s complement overflow rules for all operators and functions, except abs (which however returns the very sensible result 0x7fff.ffff) and atan2 (which returns something inconsistent).

Still a bug in atan2() as far as I’m concerned 😅

This is probably related to zep's insistence on breaking trigonometry so that the first quadrant in screen space is up instead of down.

(I really don't like that. :P)