What changed in EDuke32, build by build

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

Note: You may encounter a crash if you try to test your map and Mapster32 is running fullscreen.

Those sprites are usually decorative, and certainly not enemies!

EVENT_SOUND: triggered upon playback of any sound, this allows the "hard coded" sounds to be altered in a context-aware fashion instead of having to resort to clunky hacks like replacing them with a blank sound effect. RETURN var iable is set to the sound effect # of the sound to be played, or -1 to cancel playback. EVENT_CHECKTOUCHDAMAGE: triggered in P_CheckTouchDamage() whenever the player collides with anything. Value of RET URN is set to the result provided by clipmove() and so can be decoded in the same way. Value of RETURN when the event is over can also be manipulated to control some of the hard coded damage effects. EVENT_CHECKFLOORDAMAGE: triggered in P_CheckFloorDamage(), RETURN is simply the picnum of the floor of the sector t he player is in. Can be used to cancel hard coded floor damage effects or to make other tiles exhibit the same eff ects Other misc fixes and cleanups, including a possible workaround for Duke Plus SECTOREFFECTOR light issues wherein all SE49 and SE50 that have a statnum of STAT_EFFECTOR are simply changed to STAT_LIGHT during the STAT_EFFECTOR loop now.

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.

If one next instruction happened to be interpreted, madness would ensue, because the pointer wouldn't be aligned on the "opcode" part anymore. Also, with "seti", set current sprite index only after a successful validation.

This get into the writable variable the "linking type" of the sprite with index <spritenum>. The result is a bit field of ORed values: 1: lotag has linking semantics 2: hitag 4: extra, 8: xvel, 16: yvel, 32: zvel, 64: owner (custom only) Custom setting about which sprites have what kind of linking can be programmed via EVENT_LINKTAGS: it receives a sprite index as the 'current sprite' and is supposed to return the bit field in RETURN. An example which lists sprites and their linking hi- and lotags is provided in the state 'listusedtags' in a.m32.

This requires one tweak in drawrooms' umost/dmost setup to prevent oob access. Specifically, a coordinate difference of 0 is allowed. In the classic renderer, this would mean a one-pixel (real screen coords) height or width. In Polymost, it would currently mean a one-pixel height and zero-pixel width, but this might be subject to change.

(That is, the base shade table.) Before, we allocated each palookup buffer. For a vanilla setup, this means that we're now saving 224*32*256 ~= 1.8 megs, which might be interesting for low-memory gadgets.

First, it's unlikely in our day and age. Second, they're always free'd at the end, so allocache'ing them is incorrect.

Also, - use this in game.c and astub.c palookup loading code - when makepalookup() is passed a 0 palnum, return early. This means that 'fogpal' will silently fail when attempting to change pal 0. - in 'makepalookup' DEF command, error out if passed a pal of 0.

The syntax is as follows: makepalookup { <token-list...> } where valid tokens are * pal <palnum>: the palette number, 1 .. 250 * red <num>, green, blue (or r, g, b): the fog color components on a 0 to 63 scale. Components that are not present are assumed to be 0. * remappal <palnum>: the palette number to take the index remapping from, i.e. 21 for blue -> red. When absent, defaults to 0. * remapself: when present, specifies that the remappal is the same as the 'pal'. This is to prevent textual redundancy when overwriting existing palookups. Examples (best tested with tile #251): 1) makepalookup { pal 200 red 30 remappal 23 } This creates palookup 200 with a fog of (30,0,0) and a blue-to-yellow remapping (assuming it has not been changed before) 2) makepalookup { pal 21 red 30 remapself } This 'fogifies' palookup 21 with a red fog. 3) makepalookup { pal 21 red 30 } This overwrites palookup 21 with a red fog, but clears the blue-to-red remapping. The fog aspect of this command affects the GL modes just like 'fogpal', but the remapping has no effect for hightiles. - Also, silently clamp 'fogpal' r,g,b values to the range 0 .. 63.

Instead of drawing the rooms and masks with the classic renderer once. The captured scene is transformed to use the base palette, so that the screenshot will also show up in classic. No aspect correction is done.