Cosa è cambiato in EDuke32, build per build

In other words, for a test rectangular sector, a sprite would be inside the sector in on all 4 edges and all 4 corners. Previously, it would have been the lower right portion only (*excluding* LL and UR corners), which led to map editing issues.

Interestingly, that test case then appears to be drawn fully. Heh. Also, move one clamp from r1874 one up in the data flow chain. Doesn't seem to break textured overhead map view with Last Pissed Time.

Also add an assertion that currently sometimes fails when zooming in too much in Mapster32 textured 2D mode. Example: DNF's LADYKILLR.MAP at (46000,-14000).

The 'x' is for "extended", since its last arg is a switch of whether to disable sliding. Use that from gameexec.c.

LameDuke's shade table has 32 gradients of shade, like Duke3D. For the translucency table though, only the diagonal + one half is stored because it's symmetric (50/50 translucency).

Sprites are now considered to have out of bounds sector numbers if it is < 0 or >= numsectors (not merely >= MAXSECTORS). If such a sprite is now encountered during post-load, an attempt is made first to assign it a sector number (using updatesector()). If that fails, the sprite is removed from the map. The background is that a dozen of maps do come with such sprites and could previously corrupt the sprite list when loaded.

... like was done with clipmove() previously. Also, do some code clean up. There are no changes of functionality.

Previously, only the <0 condition was checked. However, the passed sectnums could be >= MAXSECTORS (at least in C-CON), for example when issuing 'canseespr' on a sprite not in the game world.

Whether a sprite is considered for texel-hitscan is determined on the base tile number, not the individual animated tile numbers.