Commit graph

10 commits

Author SHA1 Message Date
Inuyasha
1c81f192d8 it isn't settled until you add in the deprecation warning 2016-05-06 21:52:00 -07:00
wolfy852
5e50a51386 [2.1.15] Restore backwards compatibility for tan()
DO NOT MERGE THIS INTO THE INTERNAL REPO. This is a temporary 2.1.15 only fix. This commit allows an optional boolean for tan(), which when true will automatically shift angles by ANGLE_90.
2016-05-06 17:48:28 -05:00
Inuyasha
604ae7d072 move variable fetching from Lua out of min/max macros 2016-05-05 19:23:46 -07:00
Inuyasha
a26989c903 brevity is a virtue or something like that 2016-04-18 21:59:33 -07:00
Inuyasha
18d5d64a4d error conditions for Lua fixed point math 2016-04-18 14:50:15 -07:00
Monster Iestyn
c6a2bde7d9 Use modulo, not bitwise AND. My fault once again, whoops.
The point here is ColorOpposite(MAXSKINCOLORS) would have given an actual result of its own since MAXSKINCOLORS & MAXSKINCOLORS is still MAXSKINCOLORS. This shouldn't happen though, as both Color_Opposite[MAXSKINCOLORS*2] and Color_Opposite[MAXSKINCOLOR*2+1] aren't defined.
2016-01-18 19:46:00 +00:00
Monster Iestyn
d4f2d24921 Fix up lib_finetangent so tan() returns values starting from "0" in Lua (finetangent itself hasn't been touched)
Also fixed how the function went out of the array's bounds for ANGLE_180 and above (or negative angles)
2016-01-14 16:32:13 +00:00
JTE
ef0e61fc33 Change LUA_NUMBER to fixed_t, change angle_t handling in Lua.
Angles now go from 0 to 0xFFFF (360 degrees == FRACUNIT) instead
of using a full UINT32. Lua only has one number type, so signedness
gets in the way of using angle_t directly. This handling of angles
matches up with how ZDoom ACS scripting and the like does it.

I also changed all the integer casts and pushes of fixed_t to
their own macro in preperation for possible future seperation.
2015-05-20 23:54:04 -04:00
JTE
1e62be15ce ALL7EMERALDS is a boolean you idiot, not an integer. 2015-05-20 17:29:32 -04:00
Alam Ed Arias
b93cb1b65a SRB2 2.1 release 2014-03-15 13:11:35 -04:00