What changed in EDuke32, build by 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.

Reproduced as follows (assuming all tiles have texel-hitscan for simplicity): In E2L5, shoot the opening switch with the shotgun, aiming for the border. The crash occurs because the *other*, depressed switch tile isn't yet loaded when we index into its tile storage. Dereferencing 0+small number == BAD!

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

Internally, the last argument to neartag is now a pointer to a function int32_t (*blacklist_sprite_func)(int32_t i), which is supposed to return 1 if sprite[i] should NOT be considered for hitting. This is now used in the hard-coded neartag() calls in sector.c, but not in any way in CON (there's neither a C blacklist function provided, nor is there a possibility to define one in CON). There, all sprites with picnums >=1 and <=10 (i.e. the effectors) will be blacklisted. This remedies problems where such sprites would get in the way of switches. Note that a whitelist approach (only consider a predefined set, namely those picnums which will be checked afterwards) has back-compatibility implications since people may have used e.g. lotagged window sprites to cover a switch. Also, the >=1 to <=10 range is [sic] (the static, not dynamic values are used), since anyone redefining effector picnums is clearly out of their mind.