What changed in EDuke32, build by build

- In the A_MoveSprite() code that transports projectiles due to an SE7 (introduced in r1450 / legacy ROR), only report "success" if the transportation succeeded. - Clear newly introduced internal SPRITE_DIDNOSE7WATER flag after checking it.

- Rewrite some sprites-of-{stat,sector} loops using the SPRITES_OF, SPRITES_OF_SECT and new SPRITES_OF_SECT_SAFE macros. - In passing, identify some problems and mark them with 'XXX', but don't attempt to fix them yet. - The usual readability improvements...

Actually, the tweaked code in VM_Move() is not specific to projectiles, so other sprites now may pass no-SE7 water boundaries too, but it's most noticeable with projectiles.

That is, if submerging, the lower sector MUST have lotag 2. If emerging, the upper sector MUST have lotag 1. (Previously, emersion happened from ST 2 sectors unconditionally.) This means that the area where submersion or emersion can happen is now the same for the top and bottom parts.

... like was done with clipmove() previously. Also, do some code clean up. There are no changes of functionality.

The Lunatic build compiles with new structures for sector and wall types. They have separate members for TROR {up,down}{bunch,nextwall}, so there are no conflicts with other uses of members into which they were previously shoehorned. Also, the maximum bunch limit is bumped to 512 in that build. Currently, loading from V7/8/9 and saving to V7 and V8 are supported.

So that members needing it are checked when they're assigned to using the usual syntax. What kind of check to perform (sector, player, ... x whether negative values are allowed) is written in a declarative fashion inside the C declaration. Also, make Lunatic's MAXQUOTES be C's OBITQUOTEINDEX and bound-check an access of sprite[p->wackedbyplayer] in the C code.

Toggled with Ctrl+Shift+[KP-]. Variable 'headlight_range' controls its range. For the implementation, a new event EVENT_PREDRAW3DSCREEN was added.

Used for engine struct's (c)stat and actor[].flags members.

Previously, only the <0 condition was checked. However, the passed sectnums could be >= MAXSECTORS (at least in C-CON), for example when issuing 'canseespr' on a sprite not in the game world.

This is so that files residing in GRPs (or anywhere the engine looks for them) can be read, too.

...at the beginning of each function called back from C, and each case/default function. Called -fcache-sap. Disabled by default.

Also, - an optimization for sprite[]:setpos(). Calls to get_sprite_index() seem to be pretty slow (at least when they're not compiled). - add getzrange to the dynsymlists

Fixing movement when not loading a.m32.

This fixes an update issue: start EDuke32 without warping to a map in Polymost, change to classic, and change to Polymost again. The OSD background will be displaced.

Also, fix quote commands there.

If m32script gamevar "move_by_one" is nonzero, the some keys move the "player arrow" by increments of 1: - Without SHIFT: LEFT/RIGHT absolute x, DOWN/UP absolute y, A/Z absolute z. - With SHIFT: DOWN/UP (unbounded!) horiz, LEFT/RIGHT angle. This can be useful to debug renderer bugs that show a high sensitivity to the exact location ("are transient in space").

Face- and wall-aligned sprites are drawn using the wall routines in BUILD. However, the per-x-screen-coordinate distance (swall[]) is calculated in a way that potentially incurs great precision loss (for example 5 bits for xdimen=1280, yxaspect=65536). This leads to the starting (top) vertical texture coordinate possibly wrapping to large values, leaving an unsightly "stray line" on top of the sprite from certain viewing angles/horiz values. The approach to fix it has two parts: first, the distance is calculated using float values, preventing the precision loss. Because this doesn't fully prevent the unwanted lines, the texture coords are clamped to the mininum and maximum (0 and UINT32_MAX respectively) when calculating them for sprites. Note that stray lines may still appear at the *bottom* of sprites under certain circumstances, for example when viewing at a y-flipped sprite from above. These should be less noticable in real-world usage though. The feature is guarded by a macro HIGH_PRECISION_SPRITE in case using floating point or 64-bit integers is undesirable/impossible on some platforms.

That is, first check if the sprite is in the game world and then if it already has the desired sector or status number. This doesn't change anything in our codebase, since the return values of these functions are never examined.

The usual: declare locals more tightly, const-qualify them where it helps readability, remove dead code...

Also taking care that the USE_OPENGL=0 build builds.

Simplifying VM_FallSprite and VM_ResetPlayer2 used from Lunatic.

Meaning that only *ettsprite[THISACTOR] makes sense from CON. It did before too, because .tspr was set before each event run (and not before all runs), only that it was never nulled, which was kind of untidy.

Its only use is to have a actor -> tsprite mapping for the EVENT_ANIMATESPRITE event and .tspr will be set before it is run.

The m32script variable 'showrespawn_always' toggles whether the respawned picnum is shown unconditionally instead of only when aimed at (and locked onto the RESPAWN sprite) in 3D mode. Cool idea by Micky C. NOTE: sometimes doesn't work because of a bug in the m32script interpreter.