What changed in EDuke32, build by build

Fix 'setsprite' and 'music'. A good timing test for actors performance is the starfield of WGR2's E1L1 ("Nexus").

This should have no adverse effects or side-effects. The changes only apply if a modder chose to use completely broken functionality in the first place.

Introduced with the refactoring in r3490.

Also, fix con._setgamepalette.

From the PM conversation "gamearrays in 64-bit". A test case is the breaking glass at the beginning of the DukePlus map.

Instead of those of the translated code. Also some codegen tweaks and fixes.

Fixing movement when not loading a.m32.

- add LuaJIT's 'v' module printing trace info - translator: fix game function name definitions - revert math.fmod -> math.modf, they are different! - disable JIT compilation for a function we're getting strange crashes with - Make some of DukePlayer_t's members 'bool' on the Lua side. It's way too easy to write something like "ps.jetpack_on" where "ps.jetpack_on~=0" was meant. [Background: Kyle873 observed that Duke was always floating.] - Error out if looping in our_module(). I find this behavior more logical than returning true. - fix a couple of missed FORBID variables

Note: usually, languages call this "continue". Jeez, CON...

This fixes an update issue: start EDuke32 without warping to a map in Polymost, change to classic, and change to Polymost again. The OSD background will be displaced.

Also, fix quote commands there.

- some more outer commands - gamearray persistence - faster 'mod': use math.modf instead of math.fmod (the former is JIT-compiled) - checkavail* - THISACTOR special handling - Fix building in Windows (export A_ShootWithZvel instead of A_Shoot).

If m32script gamevar "move_by_one" is nonzero, the some keys move the "player arrow" by increments of 1: - Without SHIFT: LEFT/RIGHT absolute x, DOWN/UP absolute y, A/Z absolute z. - With SHIFT: DOWN/UP (unbounded!) horiz, LEFT/RIGHT angle. This can be useful to debug renderer bugs that show a high sensitivity to the exact location ("are transient in space").

See comments in the source for details.

Also, slightly better, though still inadequate checking.

Face- and wall-aligned sprites are drawn using the wall routines in BUILD. However, the per-x-screen-coordinate distance (swall[]) is calculated in a way that potentially incurs great precision loss (for example 5 bits for xdimen=1280, yxaspect=65536). This leads to the starting (top) vertical texture coordinate possibly wrapping to large values, leaving an unsightly "stray line" on top of the sprite from certain viewing angles/horiz values. The approach to fix it has two parts: first, the distance is calculated using float values, preventing the precision loss. Because this doesn't fully prevent the unwanted lines, the texture coords are clamped to the mininum and maximum (0 and UINT32_MAX respectively) when calculating them for sprites. Note that stray lines may still appear at the *bottom* of sprites under certain circumstances, for example when viewing at a y-flipped sprite from above. These should be less noticable in real-world usage though. The feature is guarded by a macro HIGH_PRECISION_SPRITE in case using floating point or 64-bit integers is undesirable/impossible on some platforms.

Also taking care that the USE_OPENGL=0 build builds.

Introduced in r3358, where I missed a condition inside an 'if'.

The m32script variable 'showrespawn_always' toggles whether the respawned picnum is shown unconditionally instead of only when aimed at (and locked onto the RESPAWN sprite) in 3D mode. Cool idea by Micky C. NOTE: sometimes doesn't work because of a bug in the m32script interpreter.

Use a new flag to mark hard-coded enemies, not SPRITE_BADGUY. This fixes an issue where in E1L4, a pigcop would appear in the area you have to crawl under shrunk. Thanks to LLCoolDave1 for pinpointing the range of relevant revisions.