Cosa è cambiato in EDuke32, build per build

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

The visibility calculation relies on the distance, which might not be entirely accurate in rotatesprite, so maybe it'll be too dark in some cases.

Lightmaps are already opt-in anyway.

And hook them up to cstat 128 (half-submerged, 'c' in mapster).

And hook it up to SE cstat 64 ('1' in mapster32). This disables both lightmaps and shadow maps for the spotlight; please let me know if you have a usecase where you want lightmaps but no shadow maps for specific lights.

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.

This was broken ever since updatesprite() had been forked off drawsprite() and would cause static lights to never hit static sprites until one or the other changed, after which the light would always get culled against outdated sprite geometry.

Since updatesprite() only happens once for static sprites, avoiding light culling if we hit it in a shadow pass means that sprite will never be lit as long as that happens.

With VBOs enabled, the virtual pointer to the geometry of frame 0 of a model is always NULL. This was confusing the polymer code responsible for deciding whether to enable smooth animations or not, which meant that any animation that would loop to frame 0 would do it as if animation interpolation was disabled, which looks very choppy.

This also fixes a warning when building for Windows.

Getting the texture handles without requiring invalidation means we can handle ART-animating tilenums without impacting performance too much.

Polymer has a hack that snaps horiz values of spotlights between 90 and 110 to 90 and 110 to avoid triggering aliasing artifacts with perfectly horizontal spotlights. Propagate that change all the way to the spotlight SE sprite so that the code won't think that the horiz is always different from the light and mark it invalid each frame.