What changed in EDuke32, build by build

Unlikely but possible for rogue CON code.

This "simply" requires an appropriate factor in the projection matrix. Also, get rid of a special-case factor for >=1.6 aspects (making HUD models wider then, I think).

Known as getactor/sprite[].xpanning from CON, values are 0-255. It should be assumed that this is only valid for wall-aligned sprites (currently, face sprites also pan). A test is provided in lunatic/test/animatesprites.con. It should be run in E1L2 and only with the Lunatic build.

For sanitizing underwater sections, see r4166. Also, don't print "Menu function executed successfully" when the function printed something itself.

DONT_BUILD.

Likewise for blocking wall sprites. This makes it possible to construct underwater sections containing complex spritework without losing the "underwater-ness" when over such sprites, in a backward-compatible way. Actually, the check is for bit 1 being set, but all other bits should be considered reserved.

Add an example searching for all maps containing blocking floor-aligned sprites in underwater sectors.

By detecting them in the SDL_KEYDOWN events. This list is getting a bit ridiculous...

The functions mvlineasm1, mvlineasm4 and tvlineasm2 can now be set to clamp the vertical texture coordinate (vplc), preventing the unsightly stray lines on the bottom of non-y-flipped sprites. (The first part of this effort, r3483, handled their top). However, this is only enabled for the mvlineasm ones: the vectorized variants suffered almost no slowdown (even though a PADDUSD SSE instruction would be a nice thing to have), while it was pretty significant for the sequential translucent ones. Summarizing, this leaves two cases where stray lines may appear in the non-ASM build (the saturation is NYI for a.nasm): - at the bottom of y-flipped sprites - at the bottom of translucent sprites (can be toggled by #define) Another observation is that recent GCC generates much faster code for this stuff than Clang from SVN.

So that there are no error messages like "M32 file `a.m32.m32' not found." Also, in build.c's 'save as' code, add a bound check that would probably always pass in practice, but looks a bit safer and may fail in very cornerly cases.

Instead of directly in build.c:app_main(). Previously, it was possible that an argument to an option, e.g. "WGR2" with "-game_dir WGR2", would get interpreted as the initial map to load. This in turn would attempt to execute WGR2.cfg as sequence of OSD commands -- where that file is an EDuke32 config file instead! Now: maps are passed without any options, e.g. "mapster32 [opts...] debug.map". The map file name is not added to the "additional parameters" for map testing.

This fixes a potential crash caused by violating the expected invariant sprite[g_player[player_index].ps->i].yvel == player_index otherwise.

The leak happened because a struct was hashed that had uninitialized bytes in padding inserted by the compiler. The hash string in now constructed as concatenation of three CRC32s as 8-byte hex strings, i.e. the individual CRC32s are padded with leading zeros. Note to users: because of the hash change, it's sensible to delete the 'textures' and 'textures.cache' files.

References: - r3742 - r4038 (fixing savegame screenshots, but introducing the now fixed bug)

That change confounded character-based input with e.g. HUD control under certain circumstances, see http://forums.duke4.net/topic/6845-eduke32-savegame-annoyances/ Also, BUILD_LUNATIC ... just for the hit.sect -> hit.sector change.

This reduces the proportion of time the trig calculations take of the whole preprocessing from 50% to about 13%.

Also, add hitscan test to test.lua -- a crosshair-like sprite is spawned and continuously updated to the position of where the player aims at.

The offsets (that will translate the axes for .pitch/.roll rotation) were calculated improperly with screen sizes other than 1280 x 1024 and were dependent on other related variables. The fix proceeded empirically, i.e. mostly trial, error, and some educated guesswork. (It's telling that the magic constant 1280 is needed.) A test for Lunatic is added to test.lua that will rotate SEENINES. Bug pointed out by Mblackwell.

Permitting to enable various debugging options. See "eduke32 -debughelp" for which ones those are: they were previously settable from defs_common.lua, and a new option 'strict' has been added that makes accesses to void sprites error. (That is, already "sprite[i]", not "sprite[i].some_member".)

- engine.c: comment out some unused decls with RELEASE=0 DEBUGANYWAY=1 - Lunatic: update dump.lua and v.lua - Lunatic: test/test_geom.lua: note a perf regression (wrt older LuaJIT, or I mis-configured / built something wrong)

(Auto-insertion of an inner sector from a loop happens either because the loop is created in an extended sector, or because it has been punched through a ceiling/floor into the upper/lower neighbor sector.)

- add gv.GET, gv.WEAPON, gv.RETURN - specify that sprite[].x/y/z and wall[].x/y are 32-bit ints - add an example for con.longjmp() - add an appendix listing the RETURN usage of various events

Note: the wall line will not light up periodically, but point insertion will be possible nontheless. A bit inconsistent, but I didn't want to do a full analysis of which side effects allowing a sprite highlight and a line highlight to coexist at the same time would have.