What changed in EDuke32, build by build

The problems still remains that rotatesprite behaves differently in classic and OpenGL modes with clipping boundaries specified (and maybe in some other cases)

for an assertion failure with clang. Really ought to file a bug report instead.

It looks like GCC doesn't honor the 'used' attribute with LTO. This is "fixed" by declaring the variables in question with external linkage (i.e. removing the 'static'). I consider such behavior a GCC bug, though.

The "double-click button4" had to make way for MOUSE5 in the button binds menu, but I don't think anyone cares. Savegame compatibility was actually silently broken with the MAXTILES update earlier, but I forgot updating the version...

Also a couple of other cleanup lines... might need more though, I'm not sure it's all good there.

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.

- Execute VM_ScriptInfo() when DNDEBUG is used.

certain situations (mostly cutscenes etc). This commit removes bit 1 from all flags that make it to setbrightness, the meaning of which is "don't actually update the palette". I have no idea what it was for and since the corresponding P_SetGamePalette() calls were from places like the mentioned cutscenes, I don't think it matters performance-wise.

This is in the similar vein as the set-palette deferring and it's this that fixes the low FPS in the radioactively contaminated area in AMC TC: Megabase (since setgamma() is called from setbrightness()). Again, update issues might be expected, but changing focus between EDuke32 and the desktop and back seems to restore the gamma settings properly on Kubuntu. Looks like X (or whatever above handles this stuff) maintains it on a per-application basis.

instead of shorts. This fixes their values' overflow in AMC TC megabase and probably a couple of other large maps.