What changed in EDuke32, build by build

BUILD_LUNATIC.

Hook up those from test/shadexfog.lua and some debugging ones from engine.lua.

The overall situation is thus as follows: - in C and from Lua, that member is called 'fogpal' - In CON (both C-CON and LunaCON), it's 'fogpal' with 'alignto' being an alias; 'filler' wasn't available before, either. - In m32script, it's 'fogpal' or 'alignto' ('filler' is not available any more)

That is, if that member has a nonzero value, that one is taken for the color of the GL fog instead of (most of the time) sector[].floorpal. "Sky sectors", that is, skyboxes or simply parallaxed floors/ceilings are *not* handled.

The state quries the user for four values: ref. picnum, target picnum, max. ldist and a lotag. Then, for all sprites i (of ref. picnum), for all sprites j (of target picnum), if ldist(i,j)<=maxldist, sprite j's lotag is changed to the provided one. Also add lunatic/test/maputil.lua, containing a similar function but allowing to customize the selection predicates of the ref. and target sprites, as well as the action to carry out.

Also, extend the documentation for r_usenewshading a little. Specifically, note when the different modes were introduced. BUILD_LUNATIC.

It was plainly noticeable in the editor's tile info display, for example.

This is done by factoring out some polymer.c:polymer_getbuildmaterial() code into polymer_eligible_for_artmapping() and using that. The one in polymer.c can still determine to not use ART mapping on some ("rare"?) occasions, so it's not 100% in sync.

- factor out eligible_for_tileshades() - remove some rendmode 1 code - move some auto vars further down

engine.lua: linearizeBasePal(), mapster32 only test/shadexfog.lua: create_depth_shtab(), create_vismarker_shtab()

With this mode, the near distance of the linear fog is always 0, unlike being negative with r_usenewshading 2.

Fix a case in G_MovePlayers(), where the player sprite's shade is approached toward the ceiling/floor's shade. Before, it could stop at one above or below!

... or another 'spriteflags' or 'sprite*' directive.

This flag is set from C for some enemies that should not be pushed back when damaged, such as TANK. Both the tile flag and the per-sprite flag are used (i.e. the ultimate flag value is the XOR of the two). Add currently non-functional example to test.lua that attempts to set this bit for NEWBEAST.

Make Mapster32 save as map-text if there is a wall with non-zero 'blend'.

DONT_BUILD.

Given highlighted sectors, these take the arithmetic mean of their ceiling's or floor's (respectively) z, removing the slope bit from all, and setting the new z to the mean one, rounded down to 1024 Build z units (one PGUP/PGDN). BUILD_LUNATIC.

BUILD_LUNATIC.

We shouldn't be using its actor[].t_data[8] because that one is used by the sprite rotation-fixing system (which fixes STAT_FX sprites to the positions relative to the pivot, too). Test case source/lunatic/test/delmusicsfx.lua still passes with this modification.

BUILD_LUNATIC.

engine.setupDebugBasePal() set up the water base palette such each of the first 15 "ramps" of 16 consecutive colors has a single, "representative" color. For example, color indices 0-15 and black, 16-31 are dark gray. In shadexfog.lua, list remappings from LOOKUP.DAT that are expressible as remappings of 16-tuples.

- Mapster32: before loading LOOKUP.DAT, set palookup[0][239]=239 to make an identity map of the base shade table's shade 0 - Rewrite color index remapping case of makepalookup() for clarity BUILD_LUNATIC.

Also, error if didn't read enough data and account for TITLE and REALMS swap between basepal number and on-disk order (sigh).

Lunatic: also, add an additional argument 'moreblends' to engine.savePaletteDat() and document that function. See test/shadexfog.lua for a "user-friendly" wrapper shadexfog.save() which prints success or errors.

The function now writes out a full PALETTE.DAT: base balette, shade table and translucency table.