What changed in EDuke32, build by build

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

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.

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

The bug was introduced with SAMESIZE_ACTOR_T enabling in r2208. This fixes being unable to read the messages in A.Dream* by zykov eddy.

This fixes an integer overflow when a distance is calculated later.

That is, "clang -ftrapv" builds don't abort almost immediately after entering a level. There are various classes of overflow bugs, needing different handling: - Some texture mapping code was written with signed integer wrapping semantics in mind. In some places, we're able to get away with unsigned casts. - sometimes, we really need a wider range, like when calculating distances or dot products - negating INT_MIN. Here, we cast to int64_t temporarily. Note that if the result is 32-bit wide, no 64-bit code may actually need to be generated. - shifting into a signed integer's sign bit. We cast to uint32 here. - in hitscan(), at the "abyss crash prevention code" comment, it's clearly the other code that is better... This is not merely done for pedantry, but rather makes it easier to track down overflow bugs having a real impact on the game.

- hitscan & related types and constants - profiling with gethitickms - translator: eval the opening parts of block commands early - fix getbunch

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!

The latter is only for development, since the embedded version already has a undeclared-var-reference handling similar to that. Also fix parm2memberpat.

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.

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.