Cosa è cambiato in EDuke32, build per build

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

(More precisely, in renderDrawMasks()'s check "does the maskwall separate the tsprite center from the camera?".) This provides more reasonable rendering order when the sprite (as drawn) is heavily biased to one side of the maskwall. Note [1]: mask/mask intersections are in general problematic since there is no further subdivision. For opaque objects, the OpenGL modes "work around" the issue thanks to the depth buffer. See: - 'mask_drawing_order.map', the STEAM sprites which by position are all on the other side of the right-hand side fence, but as drawn may or may not be more towards one particular side. (The topmost one with xoffset 50 is the first to be drawn behind it; note that 'picanm[STEAM].xofs == -47'.) - Issue #136, the first example screenshot. However, there, the fence intersects the STEAM sprite quite exactly in the middle (as drawn), so note [1] above applies.

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.

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.

This makes it possible to set up editor colors at startup (from m32_autoexec.cfg). For example: script_expertmode 1 do for i range 256 ifge i 33 { set editorcolors[i] i } script_expertmode 0 Use this method in the description of how to get old-style 2D colors in tiles.cfg and suggest an alternative color index pair.

Without an argument, it prints the current state.

- bump MAX_TILE_GROUP_ENTRIES to MAXUSERTILES - in loadtilegroups(), only assign a tile color if it wasn't already assigned - allow "hidden" tile groups by omitting the hotkey - Tweak the description added to tiles.cfg

Meaning tilegroup's 'colors' directive. Also, to the packaged tiles.cfg, add a description of how to emulate the earlier Mapster32 sprite coloring for one tile group.

- draw ticks above the palette "ruler" - draw all editor colors (colors in editorcolor[])

<col> is the editorcolor[] starting index <idx> is the actual color index start <idxend> is the actual color index end So, editor colors from <col> onward will be mapped to [<idx> .. min(<idxend>, 255)]. Takes precedence over '2dcol'.

Also a similar stylistic tweak in parsetilegroups().

The problem is that it stays a few seconds afterwards, obscuring information on the status line.

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

At the very least, this makes it easier to decide for one option ("Connect yellow ceiling w/ blue floor (1) or (v)ice versa?") when one of the differences is zero, which might have occurred from temporarily breaking TROR links.

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.

This feature only makes sense with the complete de-selection of a set of sectors, i.e. when pressing RAlt to do this, not adding or removing sectors to/from the set of already highlighted ones.

For values that are displayed in hex. Patch by The Mechanic, with modifications.

Bug noticed and fix located by The Mechanic.

Similarly to how -5 and -7 and are accepted since r3859.

This is necessary to hide the mouse cursor in some settings (such as with the debug build under Xfce). DONT_BUILD.

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/

See r5024 and the added comment.

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.

This prevents an oob access when rendering, the one observed was at polymer.c:4255.

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