What changed in EDuke32, build by build

This allows for CON screen display code to use menu animations. The following is an example of how to adapt screen features that should animate. before: onevent EVENT_DISPLAYMENUREST ifvare current_menu 0 // main menu { setvar x 1 setvar y 1 rotatesprite x y zoom ang tilenum shade pal orientation 0 0 xdim ydim } endevent after: state DisplayMenuCommon ifvare RETURN 0 // main menu { getuserdef[THISACTOR].m_origin_x x getuserdef[THISACTOR].m_origin_y y addvar x 65536 addvar y 65536 rotatesprite16 x y zoom ang tilenum shade pal orientation 0 0 xdim ydim } ends onevent EVENT_DISPLAYMENUREST state DisplayMenuCommon endevent onevent EVENT_DISPLAYINACTIVEMENUREST state DisplayMenuCommon endevent

This makes sure that the engine arrays have sufficient space allocated for usage in Mapster32's 2D mode, for example from drawmapview().

- t{sector,wall}type are simply typedef'd to the non-t versions - make FORCE_INLINE unconditional of DISABLE_INLINING (otherwise there are multiple definitions of these functions) - update lunatic/doc/lpeg-lunatic.patch to apply against the LPeg 0.12 I just downloaded

In setview(), we now assert windowx2 < xdim. The only calling places where its non-violation is non-trivial to ascertain are (1) showview from CON and (2) draw-to-tile for look-sideways in game.c. AFAICS case 1 should be fine. Case 2 is adapted; see comments there.

// Example: Switch between tracks like radio stations. getmusicposition temp starttrackvar next_music_track setmusicposition temp Only implemented for Ogg Vorbis, FLAC, and XA. Consult the devs before using these commands.

1. If you switch away from a weapon and switch to a third when the gun is still going down, continue lowering the first weapon instead of immediately raising the third. 2. If you switch away from a weapon and switch back to it before it lowers completely, raise it from its current position instead of going all the way to the bottom.

This should prevent Lunar Apocalypse from becoming Nuclear Winter with Megaton on Linux and Mac.

By setting DISTRECIPSIZ to 131072, as far as I can see the absolute maximum that's possible with the integer scaling convention of the voxel drawing code. BUILD_LUNATIC.

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

DONT_BUILD.

Also for polymost_scansector(). These were likely of little consequence because collection in scansector() is the exception than the rule (see added comments), and because the redundant drawwalls() would find the x range done the second and following times. Also, add a bound check for sectorborder[] (the limit was probably rarely hit in practice, but the check is mandatory nontheless) and add functions printscans() and printbunches() in the DEBUGGINGAIDS=2 build.

There were various issues with that code. - It does not seem to be very meaningful to do so. - It was carried out on the same range as the sprites sorted by z coordinate (those with equal x/y) just a few lines away, effectively overriding it. The former is very meaningful, though. - It led to inconsistencies between editor and game, see http://forums.duke4.net/topic/775-eduke32-20-and-polymer/page__view__findpost__p__214873

- factor out calculation of player-relative and screen+clipped-player-relative coordinates into get_rel_coords() and get_screen_coords(), respectively - the usual beautification stuff, especially since we're now on C99

Previously, the C function clipmove() returned negative values when hit a wall (32768+wallnum) or sprite (49152+spritenum) because internally, these values were encoded into a *signed* 16-bit integer. This made no difference to C code using it, since it always proceeded by bit checks, but was inconsistent with documentation on CON 'clipmove' on the wiki. The following commands are affected too, since they use the value returned by clipmove(): 'clipmovenoslide', 'movesprite'. Also, the value of actor[].movflag ('htmovflag' from CON). Also, fix 'clipmove*' in LunaCON and add lunatic/test/checknearwall.con as an example of how to implement a being-close-to-a-wall checker as requested in http://forums.duke4.net/topic/7869-determining-closeness-to-a-wall/