What changed in EDuke32, build by build

Rotation-fixing happens for a couple of hard-coded statnums that presumably never move (DEFAULT, STANDABLE, FX, FALLER, LIGHT), but for actors it wouldn't make sense since the common case is that they do move. For this reason, bit 4 was introduced in r1934. The position of such useractors will not diverge due to error roundoff accumulation in rotating sectors (SE0, train).

The former is really only a workaround. Walls/vertical sprites/pskies with ysize 512 (and presumably greater, but this was not tested) are rendered with one shade higher at the borders (1 pixel vlines) because of a certain assumption in the ASM (see comments there). With very dark shades, the palookup[] buffer is accessed oob. We simply allocate 256 bytes more at the end for each. The latter is only for CLASSIC_NONPOW2_YSIZE_WALLS builds, which is not enabled yet. It seems to matter only for the uncommon case where the such pskies repeat in the height. A 1680x1050 window fully covered with such a sky is then rendered at about 60/85 the FPS for me (mostly due to not using the 4 pixel vline routines), so it may be leaning a bit too much on the side of correctness. A compilation switch DEBUG_TILESIZY_512 is introduced in engine.c for demonstration purposes.

This global option will set bit 1024 and clear bits 256 and 512 for all rotatesprite calls, fixing complex HUD drawing code relying on precise alignment of individual elements (widescreen rotatesprite is entirely unsuitable for this purpose).

This fixes 2nd and following rotatesprite calls drawing differently from the first in a context with custom set-up aspect, as reported by Lezing here: http://forums.duke4.net/topic/775-eduke32-20-and-polymer/page__view__findpost__p__143090 Also, back up and restore the aspect state across EVENT_DISPLAYREST.

That is, fix some oversights introduced in the preceding runs. listglobals.sh is a helper to find global accesses. Translator: add "number-conversion" warning option, max. error limit.

- more codegen - make more members const, some char unsigned - fix some "geom" metamethods - '^' operator

1) see if we actually received anything (if http://eduke32.sourceforge.net/VERSION is unavailable, this returns now instead of continuing with nonsensical data) 2) check if we're getting a token from strtok()

The redundant ones are in code like this: s->cstat = (int16_t)32768; Because the value is eventually converted to the type of "s->cstat", any casts to integral types having at least as many bits are no-ops, signedness being irrelevant due to (probably any two's complement arch targeting compiler's) bit-pattern preserving semantics of these conversions. The now incorrect one is: if (lotag == (int16_t) 65535), "int32_t lotag" being read from a wall or sprite struct directly earlier. Now, with these members being unsigned, and (int16_t)65535 equalling -1, the check always fails. The correction fixes normal switches having such a lotag ending the level immediately. In short: integer casts before assignments are unnecessary, those in reads highly relevant!

Rewriting them in the obvious way, i.e. by casting the expression to int16_t first. (That is, this commit is the reverse of r3174, but with casts applied.) This fixes at least one regression: a FIREEXT with a hitag of 0 should not be linked with same- (that is, zero-) tagged SEENINEs or OOZFILTERs. Mind the corner cases!

- provide functions instead of messing with CONTROL_*Binds directly - comment out a few more unused functions - make clear what memory (alloc'd or const char *) 'keybind' members use - for keys with no name, use "<?>"

Using non-keypad [-]/[+] or LMB + mousewheel, it was broken when a void tile was in between.

Described here: http://forums.duke4.net/topic/3857-the-crash-thread/page__view__findpost__p__141202

I think this may fix some negative "non-profiled overhead" that I have been seeing.

Notes: - Atomic Edition (Censored) -> Plutonium Pak in grpscan.c - "scale" in astub.c:drawtileinfo() is incorrect, I think. - in demo.c, the gethitickms() value should be returned to a double.

This reverts r3159..r3161. Conflicts: eduke32/build/include/compat.h (Handled so that r3163's changes are kept applied.)

This requires ripping out the .proj member of tiledata_t back into ProjectileData[] again because it was the only one in g_tile[] that changed during the course of a game. The g_tile[] array is now also correctly flagged as "constant throughout a game" (DS_NOCHK). Savegame version bumped.

It's still not pretty though since there's no interpolation from G_DrawRooms().

Also, enable showing sprites in Mapster32's overhead view again, since that was one (the only?) use of that code path. The uninitialized read was introduced in r2927.

Instead of later in P_ProcessInput(). This fixes one drawrooms() call in between where the sectnum is the camera's, but the position the player's, which can lead to a slow "outer view" render in Polymer.