by Csonicgo » Mon Jul 13, 2015 10:03 am
A little update on a similar issue to this:
Quasar and I ran into an issue with Vela Pax concerning its ZDoom uncompressed nodes. Turns out, on ARMv7 devices, casting a double to a int (or int-like, like fixed_t) will give you undefined behaviour unless you specify precisely what signedness of said type you're casting
to.
So for example, in R_PointToAngle2, the return function was originally:
Code: Select all
return angle_t(atan2(double(y), x) * (ANG180/M_PI));
instead of:
Code: Select all
return angle_t(int(atan2(double(y), x) * (ANG180/M_PI)));
When this was corrected, Vela Pax played properly.
Did you get that yet? Instead of giving the value of angle_t as expected, GCC and Clang
both decide to punish the unclean casting code, and output 0. This resulted in all overflowing sections of the nodes (so basically facing the bottom angles of the map) to be drawn backwards or not at all, leaving large sections of the map invisible. This never pops up in x86 compiles because, for some reason, ints are always assumed to be signed there.
A little update on a similar issue to this:
Quasar and I ran into an issue with Vela Pax concerning its ZDoom uncompressed nodes. Turns out, on ARMv7 devices, casting a double to a int (or int-like, like fixed_t) will give you undefined behaviour unless you specify precisely what signedness of said type you're casting [i]to[/i].
So for example, in R_PointToAngle2, the return function was originally:
[code]
return angle_t(atan2(double(y), x) * (ANG180/M_PI));
[/code]
instead of:
[code]
return angle_t(int(atan2(double(y), x) * (ANG180/M_PI)));
[/code]
When this was corrected, Vela Pax played properly.
Did you get that yet? Instead of giving the value of angle_t as expected, GCC and Clang [b]both[/b] decide to punish the unclean casting code, and output 0. This resulted in all overflowing sections of the nodes (so basically facing the bottom angles of the map) to be drawn backwards or not at all, leaving large sections of the map invisible. This never pops up in x86 compiles because, for some reason, ints are always assumed to be signed there.
[youtube]w4Jw0G5Vhlc[/youtube]