Cosa è cambiato in EDuke32, build per 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.

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.

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

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

When requesting an increasing ramp, the upper limit is taken to be exclusive. When it is passed to G_FadePalette, only the lowest 6 bits are passed further to setpalettefade, which means that a limit of 64 is incorrectly set as 0. Also, when breaking from the fade loop, set the fade value to the end one for fadepal!

First, it's unlikely in our day and age. Second, they're always free'd at the end, so allocache'ing them is incorrect.

This additionally fixes leaks that were caused by traversing the file name list with the 'findfiles' pointer and not clearing them afterwards (even if there was a handle to the list head via 'findfileshigh').

We were writing into a string literal. Ouch!

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.