What changed in EDuke32, build by build

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.

This was supposed to go into the last commit, but I did git commit --amend without adding the changes to the index. Now I'm too lazy to sort things out.

The GAMESTATE one has to be carried out twice, first on the data from xd3_encode_memory, and then with the compressed data (because it might have increased in size, though this is very unlikely). The MOVE check is similar, though there, failure of the first check implies corrupt memory (which is why we're Bassert'ing that condition). Currently, the overflow on GAMESTATE sending happens when switching to a different map.

This fixes the glitches/corruption whereever showview is used from EVENT_DISPLAYROOMS while the scene is actually rendered to a tile instead of the frame buffer, for example because we have a tilted view or "pixel doubling" enabled. Fixing it for real (i.e. so that the showview actually completes) will require more effort.

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.

Also, correct the loadboard() return value checks in premap.c to be aware of a returned -2 ("wrong map version").

They were broken by r2666, which made their elements intptr_t instead of int32_t, but this change was not reflected in related allocation code. WARNING: players on 64-bit platforms should not attempt to load games saved with r2665 or earlier.

Note: You may encounter a crash if you try to test your map and Mapster32 is running fullscreen.