Cosa è cambiato in EDuke32, build per build

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.

For this, add a setaspect_new() setup/restore pair in M32_DrawRoomsAndMasks() like for G_DrawRooms(). With this, changing viewingrange/aspect via m32script (in a.m32: [7] -- [9] on the upper row) can only be done in r_usenewaspect 0, though.

DONT_BUILD.

Also, some minor stylistic cleanup.

- Work around a sequencing issue (assignment of searchstat) in M32_DrawRoomsAndMasks() - When having sprites highlighted and changing shade, since r1943 change every highlighted sprite's shade if one of them is aimed at. With this revision, if SHIFT is pressed while doing that, only change the aimed at sprite's shade - a.m32: Use 'break' from a state instead of 'return'. The former may be "sticky" in a way that is not intended. Needs to be debugged later. - Update instructions in m32script_ex.map DONT_BUILD.

The one introduced with r4569.

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.

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().