What changed in EDuke32, build by build

Unlikely but possible for rogue CON code.

Which was especially noticeable in the Lunatic build. Also, use glPushAttrib/glPopAttrib there.

This "simply" requires an appropriate factor in the projection matrix. Also, get rid of a special-case factor for >=1.6 aspects (making HUD models wider then, I think).

Known as getactor/sprite[].xpanning from CON, values are 0-255. It should be assumed that this is only valid for wall-aligned sprites (currently, face sprites also pan). A test is provided in lunatic/test/animatesprites.con. It should be run in E1L2 and only with the Lunatic build.

Also, if it were to be reenabled again, use execv() instead of execvp(), i.e. don't look up $PATH for the executable.

Likewise for blocking wall sprites. This makes it possible to construct underwater sections containing complex spritework without losing the "underwater-ness" when over such sprites, in a backward-compatible way. Actually, the check is for bit 1 being set, but all other bits should be considered reserved.

Add an example searching for all maps containing blocking floor-aligned sprites in underwater sectors.

By detecting them in the SDL_KEYDOWN events. This list is getting a bit ridiculous...

Compiling a 32-bit NOASM build resulted in code containing a MOVAPS instruction that accessed a memory location not aligned to 16 bytes (MinGW, GCC 4.8).

The functions mvlineasm1, mvlineasm4 and tvlineasm2 can now be set to clamp the vertical texture coordinate (vplc), preventing the unsightly stray lines on the bottom of non-y-flipped sprites. (The first part of this effort, r3483, handled their top). However, this is only enabled for the mvlineasm ones: the vectorized variants suffered almost no slowdown (even though a PADDUSD SSE instruction would be a nice thing to have), while it was pretty significant for the sequential translucent ones. Summarizing, this leaves two cases where stray lines may appear in the non-ASM build (the saturation is NYI for a.nasm): - at the bottom of y-flipped sprites - at the bottom of translucent sprites (can be toggled by #define) Another observation is that recent GCC generates much faster code for this stuff than Clang from SVN.

For a full 1680x1050 screen drawing a solid/masked wall, the FPS increases from 118 to 133 and from 114 to 116 (respectively) for me. Guarded by the macro USE_VECTOR_EXT in the source.

This fixes some init and update anomalies: before, - init would always be the graphical mode (0), but writing merely "osdtextmode" would switch it - osdtextmode would not get saved to the cfg

These were too much "looking into the implementation of a module" for my taste, hence OSD_GetShadePal() earlier.

This renders tweaks like r4122 unnecessary. Also, note a "bug" with the program generating that C code.

That is, everything that would be possible via scripting.

Also, shorten "FAILED STARTING DEMO RECORDING." message so that it fits on the screen. DONT_BUILD.

I updated the help windows to prefer these variants because they are superior to the -xSquished versions. Also, factor out the command-line processing code for the above, plus con/def modules and clipmaps.