What changed in EDuke32, build by build

Flipped reference ceilings/floors aren't handled correctly yet.

This was actually broken all the time except when ALL sectors were selected (which was what I tested incidentally when I wrote the first "fix"). D'oh!

This is to the cvar of the same name as samples/aspect.map is to r_usenewaspect.

This exposes some problems in the default/in-the-wild CONs. As usual, we'll have to retrofit sensible semantics :rolleyes:.

It's time to replace some int32s with 64-bit ints in core engine functions. The problem is that for example, the dot product is taken between vectors that may be the difference between two arbitrary points in a sector, so even if one sticks to the "no blue walls" rule, that doesn't guarantee freedom from overflows.

This was exposed by Clang with -ftrapv, which apparently also traps those.

Bang! One more invalid internals exposure squashed. Maybe one day we'll be able to call EDuke32 "stable"... Actually the offending sprite IS drawn as face sprite with shade 32 and xrepeat and yrepeat 255 for the convenience of the CON coder who will have to debug it.

Literals written out as if they were unsigned and having the highest-order bit set are all too ubiquitous, like hitscan masks for example.

Those were happening when wall drawing in an upper/lower layer "closed" too much of the "curtain" (umost/dmost) for subsequent drawing in that portal. Example: looking down the sewer manhole at the beginning of Retaliation will now render without HOM.

Also, - don't strip const when passing the char ptr to it and a couple more instances in game.c - use g_netPort when -connect parameter doesn't have a port suffix (":XXXX"), so that e.g. eduke32 -port 1700 -connect localhost is the same as eduke32 -connect localhost:1700 (-port must come before -connect, unfortunately.)

This was supposed to go into the last commit, but I did git commit --amend without adding the changes to the index. Now I'm too lazy to sort things out.

The GAMESTATE one has to be carried out twice, first on the data from xd3_encode_memory, and then with the compressed data (because it might have increased in size, though this is very unlikely). The MOVE check is similar, though there, failure of the first check implies corrupt memory (which is why we're Bassert'ing that condition). Currently, the overflow on GAMESTATE sending happens when switching to a different map.

(LUNATIC build only.) Also, a minor problem is identified. sizeof(actor_t) is 124 on 64-bit platforms, while the expected size is 128 bytes. This needs to be corrected whenever the next savegame version bump happens.

This introduces a Makefile variable EDUKE32_MY_DEVELOPER_ID, which is expected to come from the environment, so that minor disagreements/ preferences can be handled -- don't let it go overboard though! -- to keep the working directory clean of stuff that one doesn't actually work on. My ID is 805120924, i.e. "helix".

Also, print failure messages on some occasions.

Usage is from 3D mode only. When a sector (or wall) is committed to the clipboard, it (or the wall's sector) is saved, and is subsequently used when auto-aligning [;-ENTER] another sector's ceiling or floor against the reference one's. This temp. sector is reset on any structurally modifying operation except setting first walls; also, aligning extended ceilings or floors is impossible as they use .*xrepeat internally. The auto-alignment does not change picnums (this can be accomplished with the ['+ENTER] combination), but copies the orientation bits 2^{2..6} to the alignee. Afterwards, if the reference is relative-aligned, it tweaks them, so that every case where the two firstwalls are either parallel or perpendi- cular is handled correctly. It does not yet calculate the panning values.

This is so that people know where to enable it. One day, all these debugging switches ought to go into the Makefiles in one form or another.

It works perfectly fine without it for me, and including it for no reason is just an annoyance to other people building from source.

Defines SPRITES_OF(Statnum, Iter) and SPRITES_OF_SECT(Sectnum, Iter) [The first is so that STAT_* can be substituted for Iter and it reads nicely.] Usage should be self-explanatory, but one thing to keep in mind is that the sprites that are iterated over MUST NOT be deleted.

This fixes the glitches/corruption whereever showview is used from EVENT_DISPLAYROOMS while the scene is actually rendered to a tile instead of the frame buffer, for example because we have a tilted view or "pixel doubling" enabled. Fixing it for real (i.e. so that the showview actually completes) will require more effort.

This is done by kopen4loadfrommod'ing and immediately closing the file (since the checker is still run from there when not ingame). On my system, times were like 0.12 ms, 0.2 ms and 0.5 ms for each openfrompath/findfrompath, openfrompath/Bopen and SHGetFileInfo respectively, so it shouldn't have a too noticable impact on initial loading times.

I experienced the following on Windows XP: a few openfrompath() --> findfrompath() calls were taking enormously long (4.5 secs) to complete, having been passed a file name like "//bla/qwe.asd". My guess is that Windows then tried to interpret these as a network FS path in access(), and the 4.5 secs represents a timeout value.

The first means that the expensive (~0.5 ms) SHGetFileInfo() calls won't inter- fere with smooth gameplay, but files that are opened only at game-time like sounds won't be checked. The second means that there are now less false positives, i.e. warnings about files that would be found due to the check-all-{upper,lower} hack.

This fixes the crash on Wii when looking sidewards (e.g. when dying), but makes the tilted view look more pixelated. The problem was that an attempt was made to render onto a 640x640 tile for the rotated view, but the base engine arrays were too small for that.

- make allocatepermanenttile() return intptr_t - the usual

Also, correct the loadboard() return value checks in premap.c to be aware of a returned -2 ("wrong map version").

Most of the time, Windows file name lookup is case-insensitive. Reading the docs (see MSDN's CreateFile help, for example), it seems like case-sensitivity can be controlled on a per-file basis where applicable (NTFS), but people should be concerned about matching case in the DEFs/on disk *especially* in that case. Also, note that this hack will not always help on systems with case-sensitive lookup.

When a file from the local file system is opened, its real file name is gotten with SHGetFileInfo() and compared against the one that was passed. In the case they're not identical, a warning is issued. This is one step towards eliminating mismatched file names in DEFs etc., which cause trouble on systems that look them up case-sensitively. However, it's not perfect because the issue is trickier than it appears on first sight. For one thing, this will only check the last (i.e. file) part in the path, falsely accepting mismatched directory names. However for these, it reports them ruthlessly, even for those names where the try-other-case hack (try all uppercase, all lowercase) would find the correctly-cased file.

They were broken by r2666, which made their elements intptr_t instead of int32_t, but this change was not reflected in related allocation code. WARNING: players on 64-bit platforms should not attempt to load games saved with r2665 or earlier.

- alloc_multimapstate() helper - make g_netMapRevision a uint32 and store save->revision in sequence order (without &(NET_REVISIONS-1)) - one assert, one XXX comment, stylistic changes

This should be more correct, since previously, the saved PNGs were way too contrasty when looked from within a browser. Now, they'll always be slightly darker than in-game (assuming one has a gamma greater than 1).

The default C99 mode is giving us linking errors from xdelta3.

For Lunatic, we'll want to get rid of the t_data --> script indirections, since the latter will be no more. Thus, all parameters are saved in t_data directly. For the normal build, there are no changes, only stylistic tweaks.

Those sprites are usually decorative, and certainly not enemies!