What changed in EDuke32, build by build

... instead of relying on indirect inclusion via duke3d.h.

- Always parse 'animsounds' defs - don't print "ignored frame/animation definition" warnings

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.

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

If enabled, this makes the following arrays be allocated statically: spriteext, spritesmooth, sector, wall, sprite, tsprite, while necessarily disabling the clipshape feature (because it relies on setting sector/wall to different malloc'd block temporarily). To compile, pass DEBUGANYWAY=1 in addition to RELEASE=0 to 'make', and it's really only useful with CC=clang, of course.

- hud_orientation now uses proper bitwise operations - clean up whitespace

Always malloc that buffer. This allows us to remove suckcache() from cache1d.c, which I believe to be buggy (see comments in the source).

- 'whitecol' was defined in the engine and in build.c, use only the engine one - make cachesize, artsize, artversion static in engine.c - undo some formatting havoc presumably done by astyle

It is likely that this is the value it used to have at some point, because the MAXTILEFILES macro equals 256 and is as old as the Duke3D source. loadpics() now refuses to load an ART file with localtilestart or localtileend out of bounds, or if localtileend<=localtilestart (i.e. no tiles in ART file, or nonsense). Also, on 'invalid art file version', continue instead of returning. Note: this does not increase the maximum number of tiles, which is still 15360, it only gives a bit more freedom to arrange them (well, into more art files). Also, I don't see what anyone keeps off from packing any number of tiles (from 1 to 15360) into an art file. Old EDITART limits?

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.

The second one is passed to the 'mouseb' variable, but the game currently can't map it since ud.config.MouseFunctions[] would have to be enlarged, breaking savegame compatibility. Works both for the Windows and SDL layers. For the latter, instead of using the SDL_BUTTON_X1/X2 macro constants, I'm using 8 and 9, since that is what SDL (and incidentally or not, xev) gives me for those buttons.

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.

Also, for debugging builds, show this message from verbosity level 1 on.

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.