What changed in EDuke32, build by build

Internally, updateanimation() now takes a third parameter 'lpal'.

This may fix compilation for optimized builds with GCC or clang where the compiler would otherwise decide that those symbols are unused.

Ideally, we would also warn when setting WEAPONx_SHOOTS to negative values, but we'd have to intercept CON's setvar's and it wouldn't be pretty.

- fix one bound-checking line - rewrite two lines in astub.c to potentially not overflow an int16 - make tiletovox[] an array of int16's

The cause was a combination of many factors. First, Polymer requires the start-drawing position to be inside the sector to draw (deviations lead to incorrect drawing). This was violated by the game, because it interpolated the current and next tic position without updating the sectnum, leading to inconsistencies especially when passing through narrow sectors. Polymer worked around it by doing an updatesector() each frame, however this works poorly for maps with overlapping geometry such as SoS or RoR. The solution to this is to add a new engine function, updatesector_onlynextwalls(), which searches the sectors (via nextsector) in breadth-first fashion instead of from 0 to numsectors-1, like updatesector does when it fails for the *immediate* nextwall neighbors. Internally, the breadt-first search helpers are moved into the engine.

so try and steal it back"), prevent calling IDirectDrawSurface_SetPalette() with NULL arguments, causing a crash. It's happened for me on Vista, when initially changing from 8-bit to 32-bit mode.

I didn't have much success in finding bugs using it, but it works out-of-the-box on my setup, so it may be useful in the future.

It turns out that with model interpolation, out-of-bounds frame numbers may be generated with thinned out models, so disable it until I can sort out what's wrong with it. Also, minor code cleanup.

Since the original source code release of Duke3D, there was a potentially dangerous hack where actor[].dispicnum was set to -4 to signal "this actor should not have a floor shadow for this moment" (it doesn't really work, if you ask me). Now, use another bit of actor[].flags for that purpose because setting any picnum members to negative values asks for trouble.

E.g. this should work correctly now: // FLY_BY, PIPEBOMB_EXPLODE, OCTA_DYING animsounds logo { 1 244 64 14 64 144 }

crashes. Usually, after loading a game, some wall tiles are tweaked depending on whether adult mode is enabled or not. If it's not, those wall picnums are replaced with blank or broken screens. If it is, they are restored from the wall's .extra member. Apparently though, Mapster32 leaves some .extra members floating around even after deleting a TROR nextwall link (it's used as the 'lower wall index'). Because MAXWALLS is greater than MAXTILES, this may produce out-of-bounds accesses and corrupt memory (besides setting wall tilenums to nonsensical values) later in the game. Other than that, the change only affects loading savegames created with adult mode OFF. Kinky TV screenies simply won't be restored then.