What changed in EDuke32, build by build

Introduced in r3207. Oops.

This may happen if no title/end music is defined from CON. Thanks to Zaxtor for the bug report.

In A_RadiusDamage(). The code snippet that is disabled for such actors increases the damaged actor's .xvel by (4 times the) damage amount and is responsible for the strange effect of enemies becoming faster TOWARDS the player on being hit with an RPG frontally. Thanks to Fox for a keen eye.

DONT_BUILD.

The one introduced with r4569.

That is, make interpolation work properly there -- both when 'using' a VIEWSCREEN and when rendering the scene onto a TILE_VIEWSCR. This makes a difference only if the camera is in a moving sector.

- At a given time, at most one viewscreen may display TILE_VIEWSCR, namely that one which is g_curViewscreen - sync kinds of distance to compare against VIEWSCREEN_ACTIVE_DISTANCE (was Manhattan vs. dist(), now both the latter) - fix resetting to VIEWSCREEN tile when player is greater from it than that distance. When the player is closer to it again, it is *not* reset to TILE_VIEWSCR. - more sync'd g_curViewscreen and sprite[i].yvel (for 'i' being the viewscreen sprite) Note: in a multiplayer context, this needs to be thought about once more.

These will be bitwise-OR'd.

Fixes bug reported here: http://forums.duke4.net/topic/1348-mapster32-problems-and-bugs/page__view__findpost__p__213759

The only semantic change is that an out-of-sync instance of a distance to check (viewscreen sprite <-> player sprite) is changed in actors.c:G_MoveStandables(), from 2048 (as in Duke3D 1.5) to 8192, now represented by the define VIEWSCREEN_ACTIVE_DISTANCE. I have not yet observed any change in behavior regarding this change (but there ought to be one). Also, in DNCOORDS display, print 'totalclock' count, too.

This prevents displaying W_FORCEFIELD+1 masks (as e.g. in front of viewscreens) completely black with ART mapping. The old behavior, which is inconsistent with classic, is kept for one-sided masked walls, though.

So that stack traces can be gotten with optimized DEBUGANYWAY builds, e.g. for Linux's 'perf' --> flame graphs. DONT_BUILD.

DONT_BUILD.

Also, some minor style cleanup in game.c. DONT_BUILD.

BUILD_LUNATIC.

Now passed as last arg 'noFloorPal' to makepalookup(). Used as follows: - from loadlookups(): *false*, i.e. do take over floor pal. - from generatefogpals() [default fog pals] and fillemptylookups(): *true*, i.e. don't take over floor pal - from DEF 'fogpal': true - from DEF 'makepalookup': take over flag from pal from which we are remapping, or set to true if remapping from pal 0 - (CROSSHAIR_PAL: true) This should make the issue reported in http://forums.duke4.net/topic/775-eduke32-20-and-polymer/page__view__findpost__p__197583 resolve in a natural manner.

- 'nofloorpalrange' DEF token: now handled for both game and editor (for the latter, it's effective only for "shade preview" mode, [']+[X]). - in generatefogpals(), assign g_noFloorPal[] = 1 for every generated (default) fog pal; get rid of its return value / g_firstFogPal

This reverts/corrects two semantic changes of r4639 as far as what is now voxmodel.c (formerly part of mdsprite.c) is concerned. One correction ends up having no effect (m->bscale is always 1.f for voxel models, as far as I can see), but is the proper rewrite. Also, in osdcmds.c:registerosdcommands(), tweak two help strings.

Since we're targeting C99/C++ now, we can finally declare variables as close to their use as possible.

DONT_BUILD.

Also make three file-scope variables static.

Analogously treat maskwallscan() and transmaskwallscan(), although I could not get the respective accesses to be oob, too.

Notes: - In the 'clean' target, the "core*" arg to 'rm' was removed as I find it too unspecific. (Someone could have an unrelated file with that prefix lying around.) - The targets 'clean' and 'veryclean' now echo the commands they are about to execute. Also, in Makefile.common, resurrect sanitized Clang builds if DEBUGANYWAY=2 is passed (previously, that was triggered with RELEASE=0 DEBUGANYWAY=1).

This DOES NOT fix the more complex issue discussed at the forums.

The 'clean' and 'veryclean' targets are usually run without environment options. It is preferable if they clean out all object files that are possible with any.

The volume and level number for the music are stored in the last two bytes of the board file name array. No version bump is required.

In C-CON's qsubstr, error if <start> is not in [0 .. MAXQUOTELEN-1] or <length> is negative.

The winding of a loop -- with clockdir() -- is determined by examining the two line segments spanned between the points following a leftmost point of the loop. If the loop contains a leftmost point that belongs to the "right" side (as can happen with sliding door constructions), there's a chance that an outer loop is misclassified.

NOTE: lizmen may walk on water. I don't yet know why.

Such as "vid_gamma". In that case, setbrightness() would have been called without basepaltableptr having been initialized. The fix is by moving the preparational setbasepaltable() call from ExtPostStartupWindow() to ExtInit(), just before the OSD command dispatching.

This could happen when building outside the "classic" grid limits and would then lead to e.g. incorrect loop assignment on sector splitting. Bug reported by MetHy.

Inspired by http://forums.duke4.net/topic/7506-tror-question/page__view__findpost__p__199151 the corruption checker now checks for certain conditions of the loops of each sector. Recall that CW loops are outer and CCW loops are inner. - If a sector has no or more than one outer loop, count that as corruption (level 4 and 3, respectively). - (Disabled) For sectors with exactly one outer loop, check that all inner ones are inside it. This is currently not compiled due to an asymmetry of loopinside() for degenerate cases, similar to pre-r3898 inside().

There are no intended changes of functionality, it's readability tweaks only.

- LunaCON: support for setting userdef[].m_volume_number, getting .last_level - bump con_lang.MAXEVENTS - fix compilation of astub.c

That is, the reverse of what is returned with the first outarg. Use that in lunatic/util/foreachmap.lua. DONT_BUILD.

When that mode is enabled (see below for caveats), wall textures that have a non-power-of-two height (call it 'h') will be modified to look like in classic: Let 'H' be the next power of two greater than 'h'. The texture will be uploaded with height 'H', made up from 'h' hlines of the original texture, followed by 'H'-'h' first hlines of the same. No panning "corrections" will take place. The mode is disabled by default. Caveats/notes: * the mode requires that r_hightile is disabled * it is not implemented in Polymer * in the Lunatic build, it is ineffective when a VX map is loaded, as those display walls with NPOT height textures correctly

Note that x-flipping is determined by the cstat of the upper part of the wall (that is, the wall facing the player, not the nextwall, from which the picnum for the bottom part is taken.)

... and cull code that is dead with the X*alloc() versions since they never return NULL on requesting memory. Use something like git grep '[^Xx]\(m\|c\|re\)alloc *(' and git grep '[^Xx]strdup *(' to see places where I left the B*alloc() calls intact. BUILD_LUNATIC.

- in mdloadskin() and gloadtile_hi(), use new function check_nonpow2() (bit-twiddling) instead of loop - Replace a couple of missed literals with CACHEAD_* enum labels

Note: in polymer.c, this was buggy (but harmless) because .r is a char: if ((uint32_t)hictinting[MAXPALOOKUPS-1].r & 0xFFFFFF00) != 0xFFFFFF00)

- pthtyp pth->flags bits - Flags of the <dameth> argument of various functions - hictinting[].f / gloadtile_hi() and daskinloader() <effect> arg bits - hicreplctyp hicr->flags bits - texcacheheader cachead.flags bits

Specifically, the handling of one-way walls ([1] in Mapster32) was slightly different.