Cosa è cambiato in EDuke32, build per build

Since TILE_TILT is only allocated once, it must be done with the maximum possible size.

They classify former uses of int64_t into two classes: - coord_t: those that represent coordinates and need 64-bit precision for proper functioning with large values - inthi_t: those that were added for e.g. casts merely to prevent undefined behavior on overflow DONT_BUILD.

Currently, sprite[].filler (to be renamed) selects a blending table. If none is installed with that index, the blending table at index 0 is taken (which is read from PALETTE.DAT on engine startup). Thus, for now, the non-Lunatic build will never use a custom blending table because there's no way to register one! But the functionality is there.

Known as getactor/sprite[].xpanning from CON, values are 0-255. It should be assumed that this is only valid for wall-aligned sprites (currently, face sprites also pan). A test is provided in lunatic/test/animatesprites.con. It should be run in E1L2 and only with the Lunatic build.

In the mirror reversing code, get rid of the padding. This may produce seams, but they appear to be extremely transient and shouldn't be noticeable. In game.c, add a debugging compilation switch DEBUG_MIRRORS_ONLY.

The former is really only a workaround. Walls/vertical sprites/pskies with ysize 512 (and presumably greater, but this was not tested) are rendered with one shade higher at the borders (1 pixel vlines) because of a certain assumption in the ASM (see comments there). With very dark shades, the palookup[] buffer is accessed oob. We simply allocate 256 bytes more at the end for each. The latter is only for CLASSIC_NONPOW2_YSIZE_WALLS builds, which is not enabled yet. It seems to matter only for the uncommon case where the such pskies repeat in the height. A 1680x1050 window fully covered with such a sky is then rendered at about 60/85 the FPS for me (mostly due to not using the 4 pixel vline routines), so it may be leaning a bit too much on the side of correctness. A compilation switch DEBUG_TILESIZY_512 is introduced in engine.c for demonstration purposes.

Also, enable showing sprites in Mapster32's overhead view again, since that was one (the only?) use of that code path. The uninitialized read was introduced in r2927.

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

Some more drawing glitches remain.

Bang! One more invalid internals exposure squashed. Maybe one day we'll be able to call EDuke32 "stable"... Actually the offending sprite IS drawn as face sprite with shade 32 and xrepeat and yrepeat 255 for the convenience of the CON coder who will have to debug it.