Cosa è cambiato in EDuke32, build per build

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

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.

The showview command transforms the 320-based screen bound coordinates to the real screen bounds like xreal = (x*xdim)/320, which shows a bias towards zero: for example, for a 1680 screen width, the maximum permissible value 319 is mapped to round_to_zero((319*1680)/320) == 1674. (The rounding is implicit in the integer division). This makes it impossible for a view to cover the whole screen with any other resolution than 320x200. The new command transforms the bounds like xreal = (x*(xdim-1))/319, which would map 319 to 1679 in the preceding example.

- Help window text cleaned and made more consistent between game and editor - Added help entry for "-clipmap" - Log text for using CON, DEF, and RTS files has been made consistent - All instances of '%s' have been replaced with \"%s\" because ' is a valid filename character. (At least on Windows.)

There are instances where oob picnums may propagate to that function, so protect it. The digitanumber[z] bound check is actually made more permissive, but could also just as well be removed now.

Skill names are defined via 'defineskillname' as before, but the index of the last non-empty skill name (plus one) is taken as the skill count. So, if you only define the 6th, there will be no effect. Note that currently, there is no way to specify less than four skills because the CON parser doesn't allow the empty string for the name (it'll go beyond the line) and because the default skill names are initialized in EDuke32 too, in addition to the CONs.

Note the capitalization. I hope that this makes clashes with user variable names less likely.

Previously, the lists starting at headspritestat[MAXSTATUS] and headspritesect[MAXSECTORS] were both used as sprite freelists and were always in complete synchrony. Now, make only the statnum list keep the free sprites. This way, it has no CON compatibility implications because headspritesect[MAXSECTORS] is inaccessible there. Leave the array at its original size for now.

This might now be even more confusing for users reading both the source and CON code (where the access is necessarily still via '.clipping'), but at least reading the source now makes sense :P

This is so that in the event of a crash, no CON dump will be printed if no (actor or loadactor) CON code was actually executing at the time of the crash, confusing the users. Note: doesn't apply for event code.

The replacement of atoi with strtol in r2374 had the side-effect that numbers out of the range of a 32-bit integer were being returned as LONG_MAX/LONG_MIN instead of being converted by taking the bits and re-interpreting them (note that it was a coincidence that atoi behaved that way; to be strict, the behavior was undefined and there is no regression). Now, we implement parsing decimal integers using strtoll (with assuming "long long" being the same as int64_t) and check in which range the number falls. If it's in the range (INT32_MAX <= x <= UINT32_MAX), issue a warning; if it's not in (INT32_MIN <= x <= UINT32_MAX), warn too (though this better ought to be an error?). In each case, the bit representation is converted to the CON number type (int32 to assume maximum portability) by re-interpreting the bits [this is the same as an int/int cast, with GCC at least; more generally, it's implementation-defined per C99].

This was causing oob sector accesses with code like this: getwall[hitwall].nextsector temp ifvarvare sector[temp].floorz sector[temp].ceilingz setvar tempb 1 (from DT's HYPERCORE). Also validate quote indices passed to CON's quote and userquote commands at runtime.

Because: 1) It used to be like this; 2) guard against bad CON input.