What changed in EDuke32, build by build

Those were happening when wall drawing in an upper/lower layer "closed" too much of the "curtain" (umost/dmost) for subsequent drawing in that portal. Example: looking down the sewer manhole at the beginning of Retaliation will now render without HOM.

This was supposed to go into the last commit, but I did git commit --amend without adding the changes to the index. Now I'm too lazy to sort things out.

The GAMESTATE one has to be carried out twice, first on the data from xd3_encode_memory, and then with the compressed data (because it might have increased in size, though this is very unlikely). The MOVE check is similar, though there, failure of the first check implies corrupt memory (which is why we're Bassert'ing that condition). Currently, the overflow on GAMESTATE sending happens when switching to a different map.

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 fixes the crash on Wii when looking sidewards (e.g. when dying), but makes the tilted view look more pixelated. The problem was that an attempt was made to render onto a 640x640 tile for the rotated view, but the base engine arrays were too small for that.

Also, correct the loadboard() return value checks in premap.c to be aware of a returned -2 ("wrong map version").

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 default C99 mode is giving us linking errors from xdelta3.

Those sprites are usually decorative, and certainly not enemies!

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

- Make MAXXDIM and MAXYDIM macros be 860 and 490, respectively. tueidj says max. screen size is 848x480, but there are oob access bugs in the classic renderer when running with the maximum possible resolution - don't allocate additional sector/wall storage for Mapster (saves ~16k) - Add ud.config.UseJoystick = 1 in config.c, but make it conditional on Wii - remove one comment I no longer believe true, add one TODO comment

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?)

This was fixed with the preceding change; software mode will now always use software gamma if an ATI/AMD card is detected.

This part is a mixture of the original patch and my changes. It seems like tueidj had some trouble 1) getting OGG to work, which is why it's conditionally compiled out 2) struggling with endianness with the mixing routines? This may be also due to him missing to define two others BIGENDIAN macros (our code is in need of cleanup there). Note the change in jaudiolib/src/mix.c! Because I added my share to this part, I might have actually broken sound mixing on big-endian platforms.

For the Wii, SDL's mutex functionality is used. The implementation in the original patch was wrong though, so this part required non-trivial changes.

- sdlayer.c: custom "get joystick button names" routine - jmact/mouse.c: packs some joystick events into the value returned by MOUSE_GetButtons(): bits used are 256, 512, 4096, 8192 - MOUSE_Init() --> Mouse_Init(), presumably because of a name clash? - comments out right-shift of joystick analog values by 5, maybe this fixes the scale problems with the joystick on the PC too?

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.

- bump lpeg stack limit to 1024 (hack) for long if/if/if...else chains - lexical: newline, EOF and whitespace; "bad" identifiers; hex literals, newline terminated strings (allow empty string) - syntax: allow nesting of array expressions, it's easier than special-casing; handle issues with structs expecting parm2 (hackish); userdef; switch/case/default - fix parsing some commands; mind prefixes! - frontend: if failing match, print last keyword and its position; warn on "bad" identifiers (one per such); batch processing from command line - Files that locate finds from my linux box now pass (except where there are really syntax errors).

Specifically, it was in the "determine searchwall when aiming at floor or ceiling" part. Now, if prsectors[]->ceil.plane (or ->floor.plane) is NULL, we set the searchwall to the sector's firstwall and return.

- 4 instances -> HandleSE31 - 4 instances -> MaybeTrainKillPlayer - 2 instances -> MaybeTrainKillEnemies - move a couple of variables into inner blocks and add 'const' for easier reading In passing, fix a minor glitch where the squishing sound of an enemy that got run over by an SE 6 or 14 car would appear to originate from the SE instead of the enemy's last position.

This properly fixes the unwanted vertical lines.

This has been there since searchbottomwall introduction in r1466.

Previously, we only set the viewingrange according to the physical screen's dimensions, but didn't correct yxaspect for a potential non-square pixel ratio.