Cosa è cambiato in EDuke32, build per build

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

In setview(), we now assert windowx2 < xdim. The only calling places where its non-violation is non-trivial to ascertain are (1) showview from CON and (2) draw-to-tile for look-sideways in game.c. AFAICS case 1 should be fine. Case 2 is adapted; see comments there.

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.

BUILD_LUNATIC.

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.

Also, draw it at shade 18 and don't use fullbright colors.

No functional changes, but a (commented out) debug line for an oob read of the frame buffer when the mirror covers the whole screen is inserted.

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.

This prevents computing a shift value outside of [0..31].

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.

The idiv instruction also signals an FPE when the resulting *signed* quotient overflows, so we simply use div instead.

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

This was introduced with r2771, which fixed e.g. AMC TC city_si's mirrors, but instructed the base drawrooms inside yax_drawrooms to not correct the passed sectnum. Therefore, stuff would get drawn wrongly when passing sector boundaries, like from the platform to the rails in trueror1.map.

Some more drawing glitches remain.