What changed in EDuke32, build by build

Use a new flag to mark hard-coded enemies, not SPRITE_BADGUY. This fixes an issue where in E1L4, a pigcop would appear in the area you have to crawl under shrunk. Thanks to LLCoolDave1 for pinpointing the range of relevant revisions.

Whether a sprite is considered for texel-hitscan is determined on the base tile number, not the individual animated tile numbers.

One use was in determining the ray vector for the mouse-aiming hitscan in the editor. Unfortunately, the change doesn't make it any less broken in Polymost, even if the two instances were out of sync.

If enabled, dragging wall vertices will correct the xrepeat after the mouse button is released, so that the pre-drag absolute stretching is restored.

- Run it twice, since the first one is wrong. - Warn when attempting to align based on a top-oriented wall. When the sequence of walls to align has "windows", only the bottom parts will be correct. - Make the modifiers actually useful: * Pressing SHIFT aligns at most one wall, remove the old CTRL modifier. * The rest is as before: ALT makes the walls have (approximately) equal texture stretching, ['] (quote) aligns the immediate TROR-nextwalls.

Also, factor out 2x dup'd code of insertsprite() into do_insertsprite() and add searchwall-displaying code into package/samples/a.m32.

Also, add another flag, signifying that from the editor, also the "lastwall"s (i.e. the CCW-linked points) should get collected. This is to signal the editor that their wall lengths should be displayed, too.

- Stop using memcache on some other failure paths, particularly when failing to read from the on-disk texcache. - Factor out cache reading code (3x). - Fix endianness issues affecting big-enadian systems (one introduced by r3382, one existing before). Comment each B_LITTLE32 with whether we're converting from native to on-disk (little) endianness or back.

When reaching wall limits, it is possible that only some circle points will be inserted and the result is left unfinished.

- fix error handing with recursing events - wallsofsect iterator, sector[]:contains() - more codegen; mangle function names - m32: compinside

Reproduced as follows (assuming all tiles have texel-hitscan for simplicity): In E2L5, shoot the opening switch with the shotgun, aiming for the border. The crash occurs because the *other*, depressed switch tile isn't yet loaded when we index into its tile storage. Dereferencing 0+small number == BAD!

Preventing a continuously growing stack top and inevitable program termination. Also, commonize the error handling to live on the engine side.

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