What changed in EDuke32, build by build

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

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

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.

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.

The sprite is now properly copied for each sector it stretches across.

- Vertically attached sectors are now added to the clipsectorlist - Entirely remove the previous TROR hack from hitscan() - Instead, hitscan() now also uses clipsectorlist, and detects whether a TROR transition floor or ceiling was hit. If so, any subsequent wall hits in the same sector are skipped. This fixes the following: - Collision and hitscan checks where a sprite stretches vertically across more than 2 TROR layers. - Hitscan shots being unable to clear sloped TROR surfaces. - A potential out-of-bounds array access in hitscan()

Analogous to the previous commit, it also checks the sprites of the upper and lower TROR bunch of the sector. This handles the case where a sprite is intersecting layers, and fixes hitscan shots not hitting enemies properly in such cases.

This makes it so that the sprites of the ceiling and floor bunch sectors of the sector being checked are also iterated over. This handles the case where a sprite is intersecting TROR layers, and fixes projectiles not hitting enemies properly in such cases.

When checking if a point (x,y,z) is contained within a sector, then if x,y is contained, but z is not, it also checks all attached TROR layers. This fixes terminx/eduke32#24

TODO: Polymost

This fixes a division by zero crash if zoom == 0.

Fixes

terminx/eduke32#272

Also fix an error log message in engine.cpp logging the wrong variable.

In 'GetCornerPoints()', fix condition for when to use 'get_floorspr_points()' to include sloped sprites as well.

- 'PolymostPrepareMasks()' - 'PolymostDrawMasks()' - 'DrawDebugSpriteOutlines()' In passing: - Declare once and reuse 'isPolymost' local - In '#if 0'-d debug code, fix an inconsistency and a call by an obsolete function name