Cosa è cambiato in EDuke32, build per build

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

Annulla

9a2617e

- Consolidate psky* arrays into a "typedef struct psky_t" "g_psky" and "multipsky[]". - Factor out getting parallaxed sky properties into getpsky(). - Condense initial multi-psky setup by memcpy'ing from multipsky[]. - New function: MultiPsky_TileToIdx(). - Add new define PSKYOFF_MAX and related consistency-checking assertions. - Lower MAXPSKYTILES to 8 to reflect current usage (was 256). - Game: make multi-pskies consider dynamically-remapped MOONSKY1, BIGORBIT1 and LA. (Not very useful as the editor will still only act for the static values -- 80, 84 and 89, respectively.) An attempt has been made to preserve behavior even in strange cases, so this commit is unlikely to introduce regressions. Because of point 6, BYTEVERSION had to be bumped.

It didn't turn out that useful and was giving a warning with one of the preceding changes.

Also, very slightly tweak a factor toward a "brighter" (farther visible) scene overall to account for the "circular" nature of the fragment distance (as opposed to an "ortho" distance in Build).

Also, fix 'spriteflags' directive.

Having to tag these few variables and functions as ATTRIBUTE((used)) seems sensible, but what follows is just strange. OSD_Printf? headspritesect?

- fix getv movflags handling in VM_Move() - add actor.fall() - LunaCON: sanity-check some action members

Also, get rid of the strange filename[len]=255 hack in loadboard() and make its file name arg const char* at last.