What changed in EDuke32, build by build

Exposed by this snippet from a.m32: getnumber256 .owner "OWNER (projection picnum): " -MAXTILES Now, Alt+KP2 works as expected in 3D mode.

This requires enabling the same workaround as for Linux. Maybe it's not system-dependent at all.

This generally fixes demo playback. Before, tilesizx[]/tilesizy[] were written into twice as many bytes as needed. Now, don't do that at all.

I was checking for GCC >= 4.7, while Clangs pretends to be GCC 4.2. Use a feature test macro instead. The comment I made in r4161 regarding GCC vs. Clang code was wrong. Now, Clang generates slightly faster code for these cases (solid and masked 4-pixel wide vlines).

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

This fixes some init and update anomalies: before, - init would always be the graphical mode (0), but writing merely "osdtextmode" would switch it - osdtextmode would not get saved to the cfg

This renders tweaks like r4122 unnecessary. Also, note a "bug" with the program generating that C code.

This was caused by mismatched for types mapstate_t's animateptr[] and the global one (int32_t vs. int32_t *). Bump BYTEVERSION.

This fixes ESC in certain situations such as the editor map selection menu.

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

- Add SDL scancode -> our key code map for SDL_SCANCODE_APOSTROPHE - Remove duplicate map for SDL_SCANCODE_PAUSE

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 also exposes an actual issue. The sound definitions may be dynamically remapped, in which case they are not necessarily <=255 any more. BUILD_LUNATIC.

Most often, this had happened when casting comparison functions for qsort() like these: "int yax_cmpbunches(const int16_t *b1, const int16_t *b2)" to a function pointer type expecting "const void *". Alas, this is undefined behavior: see http://blog.frama-c.com/index.php?post/2013/08/24/Function-pointers-in-C and posts linked from it. At least two cases have not been fixed: - The savegame system maintains pointers which are either to data or a function in the generic "void *". This ought to be made into a union. - Probably also: #define OSD_ALIAS (int32_t (*)(const osdfuncparm_t*))0x1337

- Currently: only tvlineasm1 and tvlineasm2, but incomplete (no reverse translucency, nonpow2 textures will crash) - For System V AMD64 calling conventions; requires YASM

This reverts commit c7e51147f1869d42fc8365f748bb8f6bd4c6fc2f. [r3835] Conflicts: eduke32/build/src/defs.c [Dunno what caused this, but I cleaned this out. Also, the change from build.c was not reverted.]

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.

- Need to open some files in binary mode. - MinGW's "find" doesn't provide -L option, detect that.

- 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)

... by creating a struct with 'static const int' members, as recommended on http://www.freelists.org/post/luajit/Performance-implications-of-large-FFI-constants,4

Redundant for the same reason as the preceding one: the pointer has already been dereferenced at the point the check is made. Also, all 5 calls of that function pass a valid pointer (provided the pointers from which the expressions are derived are valid). Reported by Stack, too.

Clang's UBSan reports this as undefined behavior. I think that the reason is as follows: C99 6.5.3.2#1 (Constraints) says: The operand of the unary & operator shall be either a function designator, the result of a [] or unary * operator, or an lvalue that designates an object that is not a bit-field and is not declared with the register storage-class specifier. But in case of an expression like "&array[-1]", the operand ("array[-1]") does not designate a valid object. Moral: check first -- assure that an expression is valid for a particular operation before carrying it out. Keep in mind that otherwise, the compiler is absolutely free to optimize out the *check*.

Don't touch TerminX's r_usetileshades==1 or it being the default.

Fixes the undefined behavior discussed here: http://forums.duke4.net/topic/3857-the-crash-thread/page__view__findpost__p__152612