What changed in EDuke32, build by build

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.

We were writing into a string literal. Ouch!

As inauguration, move G_AddGroup, G_AddPath and struct strllist there. The header is located in build/include, because in the future, code that resides closer to (but is not strictly part of) the engine might need to be factored into here. The source file, however, is in the source/ directory.

This was broken ever since updatesprite() had been forked off drawsprite() and would cause static lights to never hit static sprites until one or the other changed, after which the light would always get culled against outdated sprite geometry.

Since updatesprite() only happens once for static sprites, avoiding light culling if we hit it in a shadow pass means that sprite will never be lit as long as that happens.

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

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

- Fix typo, correctly adding SDL libs to the tools on OS X so that makesdlkeytrans builds. - Move all mention of $(LIBS) out of build/Makefile into build/Makefile.shared because no linking takes place in the engine itself so LIBS additions were lost. This should fix USE_LIBPNG=1 on Windows at least. - Other assorted cleanup.

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

... and initengine now returns 1 if loadpalette() fails.

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

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)

These two functions draw a vertical line 4 neighboring pixels at a time. This gives a significant speed boost for a full screen solid and masked wall scene for x86_64 (where we have plenty of registers), about 60 --> 76 fps.

Also, a very minor change in the con/def module code. (int --> int32_t)

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

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

New engine variable 'int32_t Numsprites', not yet saved into savegames or mapstates. (The capitalization is to distinguish it from the often-used 'numsprites' locals or structure member names. In the editor, get rid of updatenumsprites().

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.

With VBOs enabled, the virtual pointer to the geometry of frame 0 of a model is always NULL. This was confusing the polymer code responsible for deciding whether to enable smooth animations or not, which meant that any animation that would loop to frame 0 would do it as if animation interpolation was disabled, which looks very choppy.

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)

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.

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