What changed in EDuke32, build by build

For reference, they are the following: - cache1d.c: suckcache() - build.c: compare_wall_coords() - make switch-invisible heuristic - Mapster32: old sprite search - Mapster32: manual z range - m32script: read/writearray, qgetsysstr - menus.c: savetemp()

Basically, base palettes with lower indices trump higher ones. For example, when one player is underwater and the other above, the normal palette takes precedence.

ROTATESPRITE_MAX is moved to build.h and all orientation bits from CON commands using rotatesprite are ANDed with (ROTATESPRITE_MAX-1). Some of the functions use ROTATESPRITE_MAX for different internal purposes, which will not be exposed to CON now (a good thing). Also, dorotspr_handle_bit2 is made clearer.

This makes sounds like DUKE_GET (item pickup) be heard for the second player in the splitscreen mod, too.

This includes mirrors, rooms and masks. Any value other than 0 or 1 that is returned is considered an error (reserved for future use).

... against invalid weapon indices and arguments accessed from arrays/structs.

This was narrowed to int8_t in r1625, breaking CON code that wanted to lock the player for a longer time than 127 game tics.

The event is run after drawing the scene, but before the overlays. To make a screenshot from a script, set DOSCRSHOT to non-zero. It will then be scheduled to run once after the drawing but before the above-mentioned event. The screenshots will be called mcapXXXX.{png,tga}.

The editor colors are the ones listed on page 9 of the Mapster32 built-in help.

The latter shows that "int32_t ksqrt(int32_t)" also copes with values in the range INT32_MIN..-1, effectively interpreting them as uint32_t (i.e. adding 2**32). However, this should not be relied on from CON.

Bang! One more invalid internals exposure squashed. Maybe one day we'll be able to call EDuke32 "stable"... Actually the offending sprite IS drawn as face sprite with shade 32 and xrepeat and yrepeat 255 for the convenience of the CON coder who will have to debug it.

This fixes the glitches/corruption whereever showview is used from EVENT_DISPLAYROOMS while the scene is actually rendered to a tile instead of the frame buffer, for example because we have a tilted view or "pixel doubling" enabled. Fixing it for real (i.e. so that the showview actually completes) will require more effort.

This is done by kopen4loadfrommod'ing and immediately closing the file (since the checker is still run from there when not ingame). On my system, times were like 0.12 ms, 0.2 ms and 0.5 ms for each openfrompath/findfrompath, openfrompath/Bopen and SHGetFileInfo respectively, so it shouldn't have a too noticable impact on initial loading times.

They were broken by r2666, which made their elements intptr_t instead of int32_t, but this change was not reflected in related allocation code. WARNING: players on 64-bit platforms should not attempt to load games saved with r2665 or earlier.

The remaining checks now "continue;" when an oob tilenum is found where an oob access would ensue else. Also, it's now checked for negative numbers (the message remains the same though).

The primary reason for doing this is that handing of moving sectors is significantly simplified. Because moving sectors usually don't move containing SEs/effector-statnum sprites, no special handing code is needed to move light SEs with them. Thus, this commit sets light SEs to a new statnum when they're spawned *from premap*, and a new G_Move*-like function (called G_DoPolymerLights) is added to process every sprite in that status list. This should "fix" light SEs moving together with a variety of moving sectors, but CON programs expecting the old behavior may break, therefore this commit is marked as experimental. Additionally, a problem with the old implementation is identified: it seems like the correct functioning is dependent upon the order of processing between the sector movement effector and the light SE, so this makes it another good reason for the change. (A third one is that all lights can be processed with a per- statnum loop, but CON coders should not do this until the change is considered final).

This is so that it may be intercepted in the future. The only code that's not replaced by the function call is with the CON interface to g_player[].ps->pals via player[].pals X and .pals_time. Also, comment out one instance because it's overwritten by a succeeding one.

(I.e. also restore r2232 again.) The first one is the palette restore logic in G_DisplayRest, the second is CON setgamepalette, to which the "don't gltexinvalidateall()" bit is added to mimic the first. Hightile invalidations aren't really useful for anything other than reloading them after a video mode change, IMO. These changes mean that 1) active full screen tints should (almost) always be kept with a basepal change. The only exceptions to this are when tints really have to be cleared, e.g. when changing the player view in co-op play. 2) there should be no performance issues with simultaneously changing basepals while a tint is applied

Previously, we checked whether the faded palette has changed (by way of CRC) and invalidated the textures then unless the preserve flags were set. This however could lead to wrongly invalidating them under unfortunate circumstances, e.g. basepal change from CON + tints at the same time before r2620 which reverted r2232. Now, only invalidate them if the corresponding preserve flags are clear AND * the base palette has really changed OR * the palette CRC changed and we were running on software gamma The latter means that performance-killing invalidations may still happen on GL platforms lacking HW gamma (for ATI, it's currently only disabled in 8-bit fullscreen). Also have a new global 'basepalreset' to fake a basepal change for setbrightness(), currently used when changing renderers so that going from Polymer to Polymost and back again will invalidate the Polymer textures on the second change, potentially re-applying a basepal highpal. (Still with me?)

Because gltexinvalidate*() could be called too often when setgamepalette is used while having a tint overlaid else. Pending thorough analysis/reworking of the 32-bit mode base palette handling / texture invalidation.