What changed in EDuke32, build by build

This reverts commit 6badacb4864961f3019143e1e4df1d04da37d8c4. Fails to compile on GCC 9.3.0 as found in the Steam Runtime build environment.

Prevents duplicate entries from appearing, which then crash when changed.

Fixes build on macOS 14.

Fixes

terminx/eduke32#286

This fixes a problem where the texcache file could grow without limit if something managed to corrupt the texcache index.

This fixes a compiler error on that platform, because of the nearby assumption that pthread_t is an integer type, when it is in fact a pointer on OpenBSD (and macOS).

In the final else, buff is not used, so duplicated into the branches where it is actually used.

Reverts

e10f2c8 — Duke3d: replace custom HTTP version check with https://github.com/yhirose/cpp-httplib (Build 10493)

It's actually kind of amusing that this was fucked up in just the right way for it to work anyway.

Fixes

terminx/eduke32#289

* clipmove() - No longer traverses sectors once a distance limit is exceeded, and at most traverses 64 TROR sectors at once. * hitscan() - TROR sectors added to clipsectlist after regular next sectors. Only adds TROR sectors in a single direction, and at most 64 at once. * A_RadiusDamage - only add TROR sectors if inside damage radius. Also increase MAXDAMAGESECTORS to 512, same as MAXCLIPSECTORS. Fixes glitches and error spam in maps that make heavy use of TROR.

Resolves an issue where starting the game in a low resolution and creating a savegame before switching to a higher resolution and creating another savegame could corrupt `sizeof(palette_t) * the difference in total pixel count between the resolutions` bytes of adjacent data in cache1d.

Throws out a half-assed refactor that seems to contain a mistake somewhere that results in occasional cache1d data corruption.

The instruction pointer wasn't being updated properly.

This would previously attempt invalid array access with index -1.

If the sector contains a TROR bunch, then whenever clipupdatesector() would normally return 1, instead run updatesector() and return 0 instead. The old approach did not work out in all situations. In Fury, certain flying enemies could not pass some TROR layers properly, and in AMC, trying to submerge in TROR water had the player glitch out on the surface. This exact approach had previously been used in AMC without any major issues for 2 years, before the recent TROR changes.

Invalid sectnums could previously be added to the clipsectlist if a hitscan shot passed a tror layer.

Squishing is now prevented if SE7 is present (as previously intended), or when the actor is standing on submergible TROR water.

Fixes

terminx/eduke32#283

This resolves a bug in Duke3D where the player couldn't move while shrunk if a TROR sector was present on the map. It also ensures that the original clipping is used if no TROR bunch is present inside the sector in question. This should reduce the amount of backwards-compatibility problems.

The changes are now more conservative and only affect sprites on TROR layers.

This commit adds a failsafe which corrects the given origin and destination sectnums of the "cansee()" function, by checking if the corresponding (x,y,z) coordinates are actually contained within the given sectors. The problem with TROR in particular was that the calculation done to determine the point of intersection on the TROR layer requires the coordinates to be within the given sectnums. Else, cansee() would simply return 0, even if there was a clear line of sight. This should also implicitly fix any other cases where the coordinates of the cansee() call do not exactly match up with the given sectnums.

And fix problems introduced by 9070cd2bff6d4547f0765fc483ffd4f923e24383.