Lua changes

This branch makes the following changes to Lua:

• ALL7EMERALDS has been changed to the Boolean type (returns false or true instead of 0 or 1, as it is intended to!)
• EvalMath has been removed (use _G[] to convert strings to their proper enumerated value and do the math yourself)
• lua_Number has been changed from ptrdiff_t to an explicit INT32
• angle_t now goes through a bit shift conversion when passed to Lua or retrieved, making angles in Lua no longer wrap around to the negative values and instead range from 0 to FRACUNIT.
• Adds sidedef texture (by number) and offset manipulation to Lua.
• Fixes a potential tmthing sanity check crash when manipulating sector heights outside of P_MapStart and P_MapEnd
• Completely rewrote lua_hooklib.c to marginalize its use of the Lua stack.

Most of these changes are made in their own independent commits and can be cherry-picked as needed.

Changing Lua's use of angle_t in this manner is consistent with how ZDoom's ACS handles the same problem, and enables modders access to just using FixedDiv/FixedMul functions on FRACUNIT to come up with their own intermediate angles.

To facilitate this, all cases where Lua passes a number from C or retrieves a number to C where that number is expected to be a fixed_t or an angle_t have been given their own unique macro defines, namely luaL_checkfixed, luaL_checkangle, lua_pushfixed, and lua_pushangle. This keeps the code clean of bit-shifting conversions when moving angle_t between Lua and C, and allows future revisions to potentially add similar special handling for fixed_t values (although right now fixed_t == INT32 so it is a nonissue)

+1 No objection to these changes here

+1 The first three changes are good (I've used EvalMath in a few addons before, but nothing that can't easily switched to using _G accesses like they should be doing). I'm still not quite comfortable with shifting angle_ts down in Lua, mostly because it'll break any script that relies on the current behavior (I.E. relying on the limits of INT32 to automatically clip all angle difference calculations between -180 and 180, or using values that aren't multiples of ANGLE_/ANG constants in angle calculations) but also because it'll lead to different behavior between Lua and C code, making ports marginally less intuitive (but the current behavior's already slightly inconsistent and that can be dealt with fairly easily). That said, I can understand if the change is needed to switch the Lua backend entirely to 32-bit, and since our next release will be a new major version and most WADs will need ported anyway, it's not something that can't be dealt with. (And since trig calculations in this game don't even use all 16 most significant bits of angle values anyway, there's practically no discernable loss of accuracy. Hey, we should consider switching all angles in the game to 16-bit values...)

Maybe if we added some small little "SANGLE(val)" or "UANGLE(val)" shims to the Lua backend that exist solely to clip values to the effective limits of INT16/UINT16 (respectively) values? Or whatever the functions end up being called? That'd alleviate my first concern some.

(unrelated: markdown can suck my shiny keister)

Added 1 new commit:

• dfa8ac7c - Added sidedef texture and offset manipulation to Lua.

I used "if angle > ANGLE_180 then angle = InvAngle(angle)" all over the code internally. (the InvAngle macro was invented because of me.) Dealing with angles has always been an issue. Making them naturally unsigned actually brings them CLOSER to how they're handled in the game engine normally, though.

I'm sure the only reason angle_t is a full unsigned 32-bit value is because the extra precision is used by the player camera and its controls, of course -- It would not be a notable loss to switch the value otherwise, although if you really want to change it to anything else furyhunter will surely pipe in with "Let's just make it a damn floating point value" like he does for everything. :P

Added 1 new commit:

• 6ee50e80 - Wrapped Lua MapLoad hook in P_MapStart / P_MapEnd.

At this point you can use http://catgirl.goddess.moe/wad/srb2lua_exe.zip for testing purposes if necessary to see how the changes work with your current Lua scripts and how hard it is to fix them.

How can the extra precision be used by the player? cmd->angleturn is only a 16-bit value. :P

Mmm... You have a point... Perhaps I was just a little unnecessarily worried. We might as well try it.

This commit is WRONG, I need to find where tmthing is set and wrap THAT instead. Argh!

Added 2 new commits:

• c91cd386 - Revert "Wrapped Lua MapLoad hook in P_MapStart / P_MapEnd."
• f783df71 - Reset tmthing after P_CheckSector calls from Lua

This branch is apparently causing a shitton of redefined variable types in VisualStudio or something? But I can't get SRB2 to compile with VisualStudio anyway, so I don't know how to fix it. X_x;

Added 2 new commits:

• ecdf3412 - Rewrote the entirety of lua_hooklib.c
• 120c9c5a - Change int32_t to __int32 on MSC.

Added 1 new commit:

• 6ac50138 - Only push userdata to the stack when needed!!

Something somewhere down this huge line of changes seems to have broke complex scripts in ways I haven't been able to pinpoint just yet.

Added 1 new commit:

• 06b82d17 - lua_pushfstring only allows %d not %x

^ Oh. That's why.

Added 1 new commit:

• 8a7c88fc - Move garbage collection out of Lua hooks.

Added 1 new commit:

• 0af32ee2 - Move garbage collection out of Lua hooks.

Reassigned to @Alam

Status changed to merged