What changed in EDuke32, build by build

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.

Besides being the compiler's job nowadays, they significantly inflate the size of the debugging builds.

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

The sliders themselves still permit changing values, but are drawn with a 'disabled' shade because they're non-functional with software gamma.

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

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.

This simply macro-defines various low-level networking functions.

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.

- the crosshair is displayed at the position read from the absolute pointing device - in the menus, use the hat input (that was mapped to mouse buttons in part 4) for navigation

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

This part adds support for an absolute pointing device.

I didn't add Makefile.common, because it needs to be made conditional.

The original patch was communicated to me by Hendricks, but since it didn't apply cleanly (it's based on r2182) I took the liberty of slightly messing with it for inclusion into EDuke32. Info: http://wiibrew.org/wiki/User:Tueidj/Duke3D This first part (which wasn't changed from the original patch) implements scaling arithmetic and miscellaneous pragmas, some in PPC assembly and a part of them in C. Of some interest is the fact that the Wii processor apparently lacks support for 64-bit integers, so divscale() uses floating-point math.

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.