What changed in EDuke32, build by build

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

We were writing into a string literal. Ouch!

Alongside, these make into into the header: - the 'tokenlist' type (a typedef'd struct) - the T_EOF and T_ERROR enumeration values

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.

- engine.c: move some variables into a lower block - premap.c: clearbufbyte --> Bmemset

The code in the editor was potentially doing a strcat on a strdup'd string. Also, rename AddGamePath to G_AddPath in astub.c and add CODEDUP markers because shared stuff like this ought to be factored out into a separate source file some time.

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.

See http://forums.duke4.net/topic/5362-crash-with-current-svn/

This makes the differences in these codes stand out much more clearly.

The nofloorpalrange beginning and end indices are silently clamped to 1 .. 255.

It has always annoyed me how floors with "shirt-color" type palookups like 21 affected the color of its containing sprites and HUD-drawn stuff. This commit allows one to specify an inclusive range of pals for which this should be disabled for sprites (but not for HUD stuff, yet).

We shouldn't assume a particular bytes-per-line value and use ylookup[] instead. Specifically, windowed modes on Windows use a frame buffer that always has odd x dimension.

- replace bit tweaking for big endian archs with clear code - allow palette lookups >= 128, previously we read into a signed byte

- in Mapster, pre-form the default 10 clip map names before returning from G_CheckCommandLine() so it gets loaded even if we passed no cmdline args. - malloc + strlen + strcpy --> strdup - don't need to spank dead variables ;) - we may call calloc with zero size, which isn't bad by itself, but asserting for non-null afterwards is. Allocs of 0 are implementation-defined, and may well return a null pointer (C99 7.20.3).

Make some computer Duke opponent variables in player.c static.

Gives a couple more fps for scenes where much screen estate is covered by stuff, like when holding the devastator.

With the same setup as before, a screen-filling translucent wall (with nothing drawn behind it) renders at about 7 fps faster (from 60-something fps initially)

A run of consecutive mapstates may share sector/wall/sprite blocks, but the code was deciding whether to free them solely on local properties. Now, save a reference count at the beginning of each such allocated block and free it only if it reaches zero.

Also, always print at least level 5 corruptions (that is, have no instances of completely silent corruptcheck).

This checks for about every possible type of sprite list corruption and reports back with a corruption level 5 if one of the 14 validations fail.

- start scrolling from about half of the visible page - PGUP/DGDN moves the cursor by 1/4 of the page - code cleanup (we only need one displine[80], use clearkeys())

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

Also include one comment about a currently failing assertion there.

Previously, if the sprite turned really out to be in void space, either freelist inconsistency (before the list rewrite) or oob access (now) would happen. Also add an bound-checking assert() for insertsprite's sectnum argument (it's not a bound check!)

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.

We've been running with same-sized actor_t for a while without problems now. In the unlikely event (famous last words) that an issue should pop up later, this revision should be consulted for the differences between the two versions.

The format is snd #<sound number> inst <instance of that sound>: voice <internal voice handle>, ow <owner's sprite ID/-1> (this is the interesting part)

- make a couple variables static in sounds_mapster32.c - KHz --> Hz in initialization text

- make some variables static - conditionally compile out some code with DEBUG_ALLOCACHE_AS_MALLOC - exit(1) on failure (instead of exit(0)) - some formatting

Note: I'm not really sure whether I'm initializing it in the right places.

When drawing from inside the mirror, there may be no 'bunches' (BUILD lingo, not TROR ones) collected, but following code used the first one unconditionally.

Hlines for masked and translucent masked ceiling/floor (sprites). - apply the --> 'do { ... } while (--cnt)' transformation, making these functions iterate cnt+1 times like the asm version. This also fixes an off-by-one issue where sprites or masked ceilings/floors had a one-pixel non-drawn line to the right. - This time, only declare-as-local two 'extern' globals (asm1 and asm2). It seems that I was too eager with "localing" all file-scoped vars earlier. GCC is able to remove the loads from memory inside the loop by itself, whereas clang is not. This is not trivial, since it has to prove that the 'screen' pointer passed to the functions will never alias these globals.

I have to admit, I like its grumbling.

See E4L1 for what this means.

The apparent horizon (in units proportional to pixels by a constant factor) was being calculated without normalizing to viewingrange, resulting a discrepancy between the drawn and actual up/down angle with non-default viewingranges (e.g. with r_usenewaspect=1, or when setting it from setaspect). This also means that the center-of-aim will now be the same regardless of the aspect. This fixes many derived bugs: * inconsistency w/ crosshair when shooting a gun and aiming up/down (obviously) * bugs resulting from being able to look up/down too far (garbage non-slope texture-mapping and viewing BIGORBIT skies above the borders in classic). Note: mods that had workaround logic for this bug will have to remove it...

added: sector extra; viewingrange and yxaspect before the main drawrooms call removed: randomseed

Usage of a search machine by Hendricks.

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