What changed in EDuke32, build by build

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.

New Wii control defaults for the Wii Remote + Nunchuk and the Classic Controller. This includes new code added just so that the Home key brings up the menu in-game, reducing the need for a USB keyboard. On the technical side, raw joystick access (comparable to what is available for keyboard and mouse) is now present in jmact, on the game side. (added: joystick.[ch]) Using this new raw joystick access, I replaced tueidj's hack to map A and B to LMB/RMB and D-Pad Up/Down to the scrollwheel. I made the menus more friendly to mouse and joystick browsing by adding and unifying checks and clears for various buttons and gamefuncs. In fact, the majority of the time spent on this commit was tracking down problems that appeared with the factoring and trying to understand the menu system and the way input checks are precariously executed. In addition, "Press any key or button to continue" now truly means what it says. As a result of incorporating proper raw access into control.c instead of it directly accessing the implementaiton, the program *may* no longer be affected by joystick input when it is out of focus. This follows the pattern set by the mouse, and I think this is a positive change. A small bonus: In the classic/old keyboard preset, the key for Show_Console has been changed from '`' to 'C' because '`' is taken by Quick_Kick.

NAM and Napalm can now share their con, def, and rts files if the one for their respective game is not present because the con and rts files are identical. Also, decapitalize two string literals missed in r2540.

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