What changed in EDuke32, build by build

Specifically, have a weapondata_t type mimicking the aplWeapon* arrays. Keep a list weapondefaults[] which undergoes some static->dynamic tweaks and then makes its way to the WEAPONx_XXX per-player gamevars.

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

Unconditionally enabled, but useful for comparing the behavior of the 1-column vline functions against the 2- or 4-column ones.

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.

- If aiming at a swapped bottom wall, display "Wall <wallnum> -> <otherwallnum>" - highlight pic, shade, pal, cstat in yellow then - in printext256, accept at most 3 digits for the color format string (e.g. ^123)

That is, everything concerning orientation. Previously, it was wrongly the bitwise NOT of these bits that got taken over. In particular, if bit 2 (swap bottom walls) would get pasted, ridiculousness could ensue.

The new "r_usenewshading 2" mode could darken these otherwise.

Implemented using GL_LINEAR fog. The only source of difference (besides the obvious indexed vs. true color) should now be the distance constant, which still had to be determined experimentally. Polymer implements this mode in its fog fragment program part. Parallaxed skies are always drawn with full visibility, I'm not sure if there are any maps that expect otherwise. Also, accidentally committed: factor out initialization code from polymost_printext256() into gen_font_glyph_tex(), small game.c changes.

This also means that the "r_shadescale_unbounded 0" option will work in Polymer (except on models).

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.

... instead of switch/case-ing them in A_CheckEnemyTile(). Because this requires bumping BYTEVERSION, we also get rid of the excess trailing bytes in the save game's "rest" data. (See r3052.)

The two uses are from hitscan and neartag. The functionality is reproduced exactly (assuming I made no mistake), down to different distance checking (<= vs. <).

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!

This function also changed: it doesn't handle floor-aligned sprites now, and the z offset is returned instead of set by pointer.

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

This means that the internal change done to these sprite members in r3159 is hidden from CON for backward-compatibility purposes. Note that .cstat and .{ceiling,floor}stat aren't touched, and will return unsigned values to CON.

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

Note the type change of vplce[] in engine.c: int32_t -> uint32_t.

Specifically, if the first wall of the sector-to-split is to the left or right of the *start* of the splitting line AND the sector has no TROR extensions, make these two the new nextwalls of the respective split sectors.