What changed in EDuke32, build by build

- make PGUP/PGDN and HOME/END behave as expected across all menus - in keyboard/mouse button mapping menu, draw function names that have been given custom names via CON with pal 8 for easier recognition - fix tinting of function names in mouse button mapping menu

Internally, there's a new function fade_screen_black() that implements the fading more efficiently than calling rotatesprite for classic, and uses tile 0 (assumed to have at least 64x32 size) in the GL modes. The black background of the user map selector is still done with rotatesprite and tile BLANK in every renderer.

So that the game won't exit if you write 'vidmode 4' when intending 'setrendermode 4'.

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

This means that when e.g. emerging from water hurt will change the palette instantly, but because bit 16 is added to the P_SetGamePalette call, the tinting is retained.

The implementation uses the recently introduced updatesector_onlynextwall when setspritez fails.

Of course, only when the mod/TC in question doesn't use that feature.

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

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

- enclose glbuild.h in #idndef ... sentinels - engine.c: remove unused variable 'pageoffset', make 'lastx' static - formatting

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

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.

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.

I'm decreasing EXTRATILES because I feel that it's way overcommitted. It's the max number of model-tiles that have their own skin for a certain palette, like the slimer egg in the HRP.

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

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?

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.