Cosa è cambiato in EDuke32, build per build

Note: 'skill == 0' can be obtained from the command line by either * '-m': "monsters off", or * '-s0': 'ud.m_monsters_off' is *not* set

In 'GetCornerPoints()', fix condition for when to use 'get_floorspr_points()' to include sloped sprites as well.

- 'PolymostPrepareMasks()' - 'PolymostDrawMasks()' - 'DrawDebugSpriteOutlines()' In passing: - Declare once and reuse 'isPolymost' local - In '#if 0'-d debug code, fix an inconsistency and a call by an obsolete function name

source/mimalloc/src/options.c:228:3: runtime error: call to function mi_log(char*, void*) through pointer to incorrect function type 'void (*)(const char *, void *)' source/build/src/osd.cpp:1755:44: runtime error: null pointer passed as argument 2, which is declared to never be null source/build/src/glbuild.cpp:296:9: runtime error: load of value 4294967295, which is not a valid value for type 'glsamplertype' source/duke3d/src/gamestructures.cpp:355:125: runtime error: member access within null pointer of type 'DukePlayer_t' ---- Note: we are also getting e.g. > source/build/include/compat.h:1008:72: runtime error: store to misaligned address 0x(...) > for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment due to '-fsanitize=alignment' implied by '-fsanitize=undefined'. This is left as-is.

See: https://github.com/zpl-c/zpl/pull/44 https://github.com/zpl-c/zpl/issues/45

This fixes a bug reported by Micky C on 2016-01-11 where too few points were marked to be inserted. See AMC TC SVN r2308.

The file descriptor was closed from Lua code, causing the subsequent kfilelength() to fail and attempt an allocation of (size_t)-1 bytes.

Used for example with DEBUGGINGAIDS=2, i.e. sanitizers enabled.

Make it always one of the colors that the 2D color cycles to (base color + offset in [0 .. 4]) instead of <base color>-3, as that one might be in a different color ramp.

Currently, this checks for effector sprites that are not face-aligned. See https://forums.duke4.net/topic/8324-icestation-colossus-map-broken

The latter allows one to specify a color to keep, but with r5302 the fillsector() highlights are drawn with transparency, thus making it ineffective. Add an argument to toggle transparency to fillsector() (now fillsector_maybetrans()) and two wrapper functions.

Bug noticed and fix located by The Mechanic.

With 3 modes: 0: auto-correction and warning disabled 1: auto-correction enabled (default, current behavior) 2: auto-correction and warning enabled

There's no point, really. Since the bouncemine is immobile, the tsprites will all be overlaid at one point and show the same picture, as far as I can see. Worse, since r4876, the generated sprites may draw on top of the actual one. The former have their shade always set to sprite[t->owner].shade though, and will then appear fully bright (shade -127, since BOUNCEMINE sets it like this). This fixes issue number 4 from http://forums.duke4.net/topic/8042-five-minor-problems-report/

Except: - missing braces around initializer [-Wmissing-braces]: due to union-in-struct vec3f_t - comparison between signed and unsigned integer expressions [-Wsign-compare]: in polymer.c

I didn't produce a case when this could actually have happened, but reading the code, in the case of variable 'j' it seems possible with an empty map.

That is, in m32_is2d3dmode(), also check if 2d and 3d mode resultions are the same. Otherwise, oob writes (e.g. via tileinfo_doprint()) and other thinkable niceties may ensue.

Make lunatic/test/gamearray.con run in C-CON, too.

Conceptually, this amends r4428.

It does not depend on the "swap bottom wall parts" bit being set. The fix is by matching up the related code with Polymost.