Cosa è cambiato in EDuke32, build per build

It does not depend on the "swap bottom wall parts" bit being set. The fix is by matching up the related code with Polymost.

Fixes bug reported here: http://forums.duke4.net/topic/1348-mapster32-problems-and-bugs/page__view__findpost__p__213759

This prevents displaying W_FORCEFIELD+1 masks (as e.g. in front of viewscreens) completely black with ART mapping. The old behavior, which is inconsistent with classic, is kept for one-sided masked walls, though.

It was plainly noticeable in the editor's tile info display, for example.

This fixes updating the viewscreen in Polymer's ART mapping mode.

Also, rewrite invalidatetile() for clarity.

References: - r3742 - r4038 (fixing savegame screenshots, but introducing the now fixed bug)

This reduces the proportion of time the trig calculations take of the whole preprocessing from 50% to about 13%.

- Use the proper tile sequence when multiple pskies are present in a map. However, there's still only *one* psky chosen at map load time. - Handle three horizfrac cases: * 0, psky always at same level wrt screen * 65536, psky horiz follows camera horiz (e.g. E4L9) * otherwise, fall back to default hard-coded parallax implemented as an angle fraction

Add a test case in test_tileoffsets.map.

This fixes the case marked with the silver letter C in test_tileoffsets.map. The orientation of the sprites is correct (matches classic) as far as I can see, there are now only problems with translation.

Also, add some defines for sprite cstats to build.h (SPR_*) and use them.

This changes a constant inside the panning calculation from 256 to 255 (making e.g. panning 255 and 0 the same in the "San Andreas fault" sign in E1L5) and uses the correct reference wall for the "do panning correction?" conditional. Now, the problematic walls should look the same as in Polymost.

This makes the corrections conditional on where they appear in (under-, over-, white or mask wall).

Non-pow2 wall/mask drawing in classic introduced cases where walls are drawn "incorrectly" because they were constructed with the old behavior in mind. Polymer appears to "correct" for it partially, but doesn't cover all cases. Specifically, now we have: - E1L1 first inside secret room (5000, 50000): Polymer draws like Duke 1.5, classic now draws with an offset. - E3L2 near the vault (-20000, 25000): both classic and Polymer draw with offsets compared to Duke 1.5, but they're different! This means that more research is needed into what makes these two cases diverge, even though both have the same root cause. !!! Also, mappers should abstain from using non-power-of two textures on walls until this issue is resolved in a satisfactory fashion !!!

This properly fixes the unwanted vertical lines.