What changed in EDuke32, build by build

This changes a constant inside the panning calculation from 256 to 255 (making e.g. panning 255 and 0 the same in the "San Andreas fault" sign in E1L5) and uses the correct reference wall for the "do panning correction?" conditional. Now, the problematic walls should look the same as in Polymost.

This makes the corrections conditional on where they appear in (under-, over-, white or mask wall).

I'm willing to make this one concession to correctness in the name of backward- compatibility. I think that one reason why this has never cause a crash is that tiles in BUILD are allocated in Ken's big allocache buffer, so oob accesses were dampened by that (though they hit uninitialized data).

The editor colors are the ones listed on page 9 of the Mapster32 built-in help.

The map iterator now has init/finish capability, making it possible to write scripts that aggregate data over multiple map files. One such example calculates some statistics, the other loads art metadata and looks for red walls with non-pow2 ysize tiles.

Non-pow2 wall/mask drawing in classic introduced cases where walls are drawn "incorrectly" because they were constructed with the old behavior in mind. Polymer appears to "correct" for it partially, but doesn't cover all cases. Specifically, now we have: - E1L1 first inside secret room (5000, 50000): Polymer draws like Duke 1.5, classic now draws with an offset. - E3L2 near the vault (-20000, 25000): both classic and Polymer draw with offsets compared to Duke 1.5, but they're different! This means that more research is needed into what makes these two cases diverge, even though both have the same root cause. !!! Also, mappers should abstain from using non-power-of two textures on walls until this issue is resolved in a satisfactory fashion !!!

This was introduced with r2771, which fixed e.g. AMC TC city_si's mirrors, but instructed the base drawrooms inside yax_drawrooms to not correct the passed sectnum. Therefore, stuff would get drawn wrongly when passing sector boundaries, like from the platform to the rails in trueror1.map.

Some more drawing glitches remain.

The latter is commented out, since it has to be *compiled* with script_expertmode enabled.

Related to that, it looks like out-of-bounds accesses when drawing such walls/ maskwalls or *sprites* are fixed, too. Sprites still show a stray lines on some occasions, but Valgrind doesn't complain then.

uhypsq calculates the hypotenuse using unsigned multiplication. This is permissible since for arbitrary int32s a and b, the following holds in two's complement arithmetic: (int32_t)((uint32_t)a * b) == (int32_t)((int64_t)a * b) ("Signed and unsigned multiplication is the same on the bit level.") This fixes various overflows where wall lengths for walls of length > 46340 are calculated, but does not rid us of other overflows in the same vein (usually dot products between vectors where one point is a wall vertex and the other a position in a sector).

This was actually broken all the time except when ALL sectors were selected (which was what I tested incidentally when I wrote the first "fix"). D'oh!

It's time to replace some int32s with 64-bit ints in core engine functions. The problem is that for example, the dot product is taken between vectors that may be the difference between two arbitrary points in a sector, so even if one sticks to the "no blue walls" rule, that doesn't guarantee freedom from overflows.

This was exposed by Clang with -ftrapv, which apparently also traps those.

Bang! One more invalid internals exposure squashed. Maybe one day we'll be able to call EDuke32 "stable"... Actually the offending sprite IS drawn as face sprite with shade 32 and xrepeat and yrepeat 255 for the convenience of the CON coder who will have to debug it.

Those were happening when wall drawing in an upper/lower layer "closed" too much of the "curtain" (umost/dmost) for subsequent drawing in that portal. Example: looking down the sewer manhole at the beginning of Retaliation will now render without HOM.

NAM and Napalm can now share their con, def, and rts files if the one for their respective game is not present because the con and rts files are identical. Also, decapitalize two string literals missed in r2540.

Also, print failure messages on some occasions.

Usage is from 3D mode only. When a sector (or wall) is committed to the clipboard, it (or the wall's sector) is saved, and is subsequently used when auto-aligning [;-ENTER] another sector's ceiling or floor against the reference one's. This temp. sector is reset on any structurally modifying operation except setting first walls; also, aligning extended ceilings or floors is impossible as they use .*xrepeat internally. The auto-alignment does not change picnums (this can be accomplished with the ['+ENTER] combination), but copies the orientation bits 2^{2..6} to the alignee. Afterwards, if the reference is relative-aligned, it tweaks them, so that every case where the two firstwalls are either parallel or perpendi- cular is handled correctly. It does not yet calculate the panning values.

Also factor out the code (2x) setting the alignment bits for sprites.

Defines SPRITES_OF(Statnum, Iter) and SPRITES_OF_SECT(Sectnum, Iter) [The first is so that STAT_* can be substituted for Iter and it reads nicely.] Usage should be self-explanatory, but one thing to keep in mind is that the sprites that are iterated over MUST NOT be deleted.

This fixes the crash on Wii when looking sidewards (e.g. when dying), but makes the tilted view look more pixelated. The problem was that an attempt was made to render onto a 640x640 tile for the rotated view, but the base engine arrays were too small for that.