What changed in EDuke32, build by build

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.

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.

Internally, the last argument to neartag is now a pointer to a function int32_t (*blacklist_sprite_func)(int32_t i), which is supposed to return 1 if sprite[i] should NOT be considered for hitting. This is now used in the hard-coded neartag() calls in sector.c, but not in any way in CON (there's neither a C blacklist function provided, nor is there a possibility to define one in CON). There, all sprites with picnums >=1 and <=10 (i.e. the effectors) will be blacklisted. This remedies problems where such sprites would get in the way of switches. Note that a whitelist approach (only consider a predefined set, namely those picnums which will be checked afterwards) has back-compatibility implications since people may have used e.g. lotagged window sprites to cover a switch. Also, the >=1 to <=10 range is [sic] (the static, not dynamic values are used), since anyone redefining effector picnums is clearly out of their mind.

I find this cleaner for two reasons. First, lotags won't get in the way of neartag(), so that doors and switches near constrained TROR walls can be pushed. Second, this removes the information leak so that CON coders aren't tempted to read that values directly before a proper API for that comes along. When writing out a map in-game (e.g. with dndebug), restore the respective members so that it can be loaded in the editor again.

- make PGUP/PGDN and HOME/END behave as expected across all menus - in keyboard/mouse button mapping menu, draw function names that have been given custom names via CON with pal 8 for easier recognition - fix tinting of function names in mouse button mapping menu

Ideally, we would also warn when setting WEAPONx_SHOOTS to negative values, but we'd have to intercept CON's setvar's and it wouldn't be pretty.

Resetting the gamevars might produce inconsistencies between an earlier loaded game (for example, if it was saved with different/earlier CON code), and worst of all, the gamevars that reference C variables might be overwritten (i.e. the addresses to those variable, which is very bad!).

instead of -1. Setting is still only through 'setgamepalette'.

'frequently' isn't such a good idea. Assume an actor constantly changes the palette to some value and you're attacked by a newbeast at the same time. Then the pain tinting would be reset each time the actor's code is run. This commit adds a new flag 16 to setbrightness(), meaning "don't reset the fade tinting". Its only use right now is from CON's setgamepalette command (and there, always). The change is done in the engine and thus affects all platforms.

CON code sometimes uses 'setgamepalette' from withing actors, which is a bit too frequent. Deferring the actual palette updating means that multiple requests in between two screen redraws are coalesced into one, which is desirable for performance reasons and for the reduction of 'tearing' artefacts (but not prevention, since the drawing isn't synced to the screen refresh rate with vsync off). (Did-not-)update issues might be introduced. Windows isn't touched because - I expect it to be more brittle, especially in light of the ATI HW gamma problems. - I haven't tested whether the particular performance penalty that lead to this change ('gas' in AMC TC) exists there too

the constants 0 and 1, and moveptrs may reference the script up to index 2 then (though I'm not sure whether the code is reachable with moveofs either 0 or 1), so make sure it's nulled instead of whatever happened to compile at the first two positions. Move 1 is only used once in the original cons, when frozen and being shattered.

Bmemset(..., 0, sizeof(...)) instead of clearbuf(..., MAX..., 0), because the latter would clear only half of the data on 64-bit platforms.

Actors are always moved such that _they_ clip against blocking sprites, even if their blocking bit is clear. Setting the new bit make them not clip against anything. The promary use of this is for decorative moving sprites that are spawned in masses, such as rain or snow.