Cosa è cambiato in EDuke32, build per build

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.