3 ms·

Yeah, it’s a cute optimisation, and might make sense in a game engine; I just question whether this would ever be worthwhile writing as custom code in a single

Yeah, it’s a cute optimisation, and might make sense in a game engine; I just question whether this would ever be worthwhile writing as custom code in a single game. I’m not sure I agree it’s more readable. The optimised version is reasonably regular, but it’s still longer and has more constants, hence more opportunities for sign errors and the like. It feels sort of like jumping through hoops to avoid a matrix inversion, say. Sure, matrix inversion is “slow”, but unless you’re doing it millions of times a frame it doesn’t remotely matter. If matrix inversion or atan2 is the most direct way to express a transformation, just do it that way.

dahart 4y ago
I think the atan2+sincos version is more readable, so I guess we actually do agree there. But I wouldn’t (and didn’t) use that in a game engine. For rounding and readability in a real engine, I’d name 4 of the 8 directions and look for the largest absolute value dot product. That would at least corral the constants. And I’d use (did use) f16 or integer arithmetic. One reason I have to support this kind of optimization and not reach for the trig method by default is the last time I wrote a controller system, it wasn’t limited to something as small as deciding on a single dpad-like direction, it was a much larger system that designers could author controller recognizers for, up to and including drawing shapes like a circle with the stick, or entering a time based sequence of inputs (think Contra’s famous up-down-up-down-etc-etc cheat code). If you have sequences and multiple players and high frame rate and many possible patterns to identify, that’s when efficiency of these small operations really starts to add up. I actually spent the most development time ensuring that the amount of time spent not recognizing controls was minimized, making sure that a no-op pass through the system was measured in nanoseconds and not microseconds.

dahart 4y ago

I think the atan2+sincos version is more readable, so I guess we actually do agree there. But I wouldn’t (and didn’t) use that in a game engine. For rounding and readability in a real engine, I’d name 4 of the 8 directions and look for the largest absolute value dot product. That would at least corral the constants. And I’d use (did use) f16 or integer arithmetic. One reason I have to support this kind of optimization and not reach for the trig method by default is the last time I wrote a controller system, it wasn’t limited to something as small as deciding on a single dpad-like direction, it was a much larger system that designers could author controller recognizers for, up to and including drawing shapes like a circle with the stick, or entering a time based sequence of inputs (think Contra’s famous up-down-up-down-etc-etc cheat code). If you have sequences and multiple players and high frame rate and many possible patterns to identify, that’s when efficiency of these small operations really starts to add up. I actually spent the most development time ensuring that the amount of time spent not recognizing controls was minimized, making sure that a no-op pass through the system was measured in nanoseconds and not microseconds.