What changed in EDuke32, build by build

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.

- 4 instances -> HandleSE31 - 4 instances -> MaybeTrainKillPlayer - 2 instances -> MaybeTrainKillEnemies - move a couple of variables into inner blocks and add 'const' for easier reading In passing, fix a minor glitch where the squishing sound of an enemy that got run over by an SE 6 or 14 car would appear to originate from the SE instead of the enemy's last position.

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.

Previously, we only set the viewingrange according to the physical screen's dimensions, but didn't correct yxaspect for a potential non-square pixel ratio.

Consequently, it's not saved as a setting in either the game or editor config files. We do this by calling "GetSystemMetrics(SM_CXSCREEN)" (accordingly for y) and calculating the cvar by dividing common factors, since it has to be in the form WWHH. This may fail for _really_ strange screen dimensions, so a log message is printed at the very beginning.

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.

- clearbufbyte --> Bmemset - add libm to $(UTILLIBS) to fix building of mkpalette - add self-explanatory Makefile commands: dxutils, sdlutils, printdxutils, printsdlutils

Currently syntax only. Parses the original scandcode 0x1d files, which is harder than you'd imagine given the relatively simple structure. Chokes on new-gen custom stuff.

- strip 'inline' from animateoffs() definition, remove declaration in build.h - one min/max -> clamp - one malloc/strlen/strcpy -> strdup

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.

- factor out many identical checks in a convenient function; some messages may read slightly differently now and tile ranges may be handled more strictly (error out if one of the limits is invalid) - factor out two instances of identical (up to one arg) code into tile_from_truecolpic - factor out setting picsiz[] and stuff into set_picsizanm - some checks - Make "undefmodelof" non-functional and warn. - in "animtilerange", if the tile difference is >= 64, error out since we can't store it in picanm[]

This was more or less done by trial and error rather than understanding what exactly is going on there. In any case, the code for all the different ending scenes ought to be factored out instead of being duplicated with subtle differences every time.

Allow all drivers for now; if anything, we should start maintaining a blacklist now that most Intel chips have decent enough support to be able to run stuff satisfactorily.

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.

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