What changed in EDuke32, build by build

This was actually broken all the time except when ALL sectors were selected (which was what I tested incidentally when I wrote the first "fix"). D'oh!

It's time to replace some int32s with 64-bit ints in core engine functions. The problem is that for example, the dot product is taken between vectors that may be the difference between two arbitrary points in a sector, so even if one sticks to the "no blue walls" rule, that doesn't guarantee freedom from overflows.

This was exposed by Clang with -ftrapv, which apparently also traps those.

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.

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.

Also, print failure messages on some occasions.

Usage is from 3D mode only. When a sector (or wall) is committed to the clipboard, it (or the wall's sector) is saved, and is subsequently used when auto-aligning [;-ENTER] another sector's ceiling or floor against the reference one's. This temp. sector is reset on any structurally modifying operation except setting first walls; also, aligning extended ceilings or floors is impossible as they use .*xrepeat internally. The auto-alignment does not change picnums (this can be accomplished with the ['+ENTER] combination), but copies the orientation bits 2^{2..6} to the alignee. Afterwards, if the reference is relative-aligned, it tweaks them, so that every case where the two firstwalls are either parallel or perpendi- cular is handled correctly. It does not yet calculate the panning values.

Also factor out the code (2x) setting the alignment bits for sprites.

Defines SPRITES_OF(Statnum, Iter) and SPRITES_OF_SECT(Sectnum, Iter) [The first is so that STAT_* can be substituted for Iter and it reads nicely.] Usage should be self-explanatory, but one thing to keep in mind is that the sprites that are iterated over MUST NOT be deleted.

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

Those sprites are usually decorative, and certainly not enemies!

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

Among other things, comment out very seldomly (or not at all) used sprite member macros: SV, ZV, RX, RY, CX, CY, CD, PL.

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

Previously, I knew no way of querying for graphics adapter vendors/names from anything other than OpenGL. Googling revealed a way to do this with the Windows API.

On the Wii, V7 (i.e. original) map limits are used and the maximum screen size is 1600x1200.

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.

This properly fixes the unwanted vertical lines.

Of course, it's just for the heck of it, since this setting is not saved into MAP files. I kinda like the cylindrical projection...

This has been there since searchbottomwall introduction in r1466.

Because this doesn't even seem to work on XP, we're being spammed with DDERR_SURFACELOST messages...

Previously, it was possible to leave a sector with less than three walls if a point got deleted transitively by a TROR link. Now, a proper check is done for all deletion candidates and a message stating which wall and sector is problematic is printed. Thanks for Diaz for pointing out the brokenness.