What changed in EDuke32, build by build

This trims four 4k pages of code from the release EDuke32 build and one page from Mapster32.

When this happens, parallaxmodes other than 0 will be unavailable and silently draw as parallaxmode 0. This usually happens with extremely wide resolutions.

For reference, they are the following: - cache1d.c: suckcache() - build.c: compare_wall_coords() - make switch-invisible heuristic - Mapster32: old sprite search - Mapster32: manual z range - m32script: read/writearray, qgetsysstr - menus.c: savetemp()

The spawn-time SE 17 setup uses nextsectorneighborz() which can fail (return -1) on some circumstances and would cause an OOB sector[] access.

This is mostly for debugging, since currently, Mapster32 restores sprites not in the same order as the original sprite index order. Also, expose this option from map2text.lua and mapdiff.sh.

This is really an artifact of overloading the sector fields for different uses. For copy-pasting TROR'd portions, the bug still persists.

A debug macro to test tints being stuck at the least intense non-zero value is provided in engine.c.

Noted by Nukey. See Duke3D 1.5 GAME.C line 4220.

Because rotating sectors "smoothly" by 1 BUILD ang will quickly accumulate roundoff error, this lets the user first do that as a preview and then use the manual angle rotation do carry it out for real.

This means that classic and the GL modes now look the same as far as e.g. hud_bgstretch or HUD weapons are concerned.

Use integer math; both args to setaspect are constant.

Instead of setting and resetting the [xy]dim globals, use them as locals in a block (shadowing the globals). Also, do some common subexpression elimination for clarity.

When shrunk, the player position is below the floor for some weird reason. Updatesectorz would set the sector to -1, and the view would not be drawn.

That is, use the view boundries instead of the whole screen.

This makes the code rather more readable in some places. Unlike the two preceding commits, this one is actually purely textual replacement.

The idiv instruction also signals an FPE when the resulting *signed* quotient overflows, so we simply use div instead.

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