What changed in EDuke32, build by build

On the engine side (functions starting with L_), there are now the basic parts like state creation and running code from strings and files. The game and editor can add to that by e.g. loading whatever they please into the state. Their functions start with El_ and Em_, respectively. The Lua scripts still reside in source/lunatic, even for the common ones. This is because they will be embedded into the binaries as bytecode or compressed source eventually, so their location on disk will be irrelevant.

See the next commit for details.

Also, enable showing sprites in Mapster32's overhead view again, since that was one (the only?) use of that code path. The uninitialized read was introduced in r2927.

Also, reorganize some G_DrawRooms() code a little without changing anything.

Instead of later in P_ProcessInput(). This fixes one drawrooms() call in between where the sectnum is the camera's, but the position the player's, which can lead to a slow "outer view" render in Polymer.

The command-line utility can query and set the frame rate of IVF files, since apparently encoders don't care too much about setting proper values in the IVF header. Also, add the utility to the synthesis build. On the playback side in EDuke32, get rid of the 1/(2*fps) "correction" if the FPS numerator is <1000 (presumably used in older encoders) and properly print the frame rate's fractional part.

This means that the "Keyboard Setup" should now properly reflect the bindings, except in the theoretical case of one gamefunc being bound more than two keys. (What was fixed is the one key to many gamefuncs case.)

That section was only ever read in for little profit and never written out! Keyboard input is actually dispatched as OSD commands for a good while, so that old cruft has to go!

- Remove everything using CONTROL_KeyMapping, which was only written to. - Remove unused functions, make local ones static. - Remove private function declarations in _control.h.

Also, disable drawing sprites in that mode for now.

This is done by pressing LShift and - holding down the left mouse button for scaling, or - the right mouse button for rotating the highlighted walls/sprites with respect to a pivot point determined as the center of the bounding box of all highlighted points. Note that scaling sectors isn't that easy and the current functionality is very rudimentary: there's no z scaling, no xrepeat correction, and sprites aren't touched expect for their position. The user is responsible to maintain map consistency, for example to prevent wall-lines of the same sector crossing each other.

This fixes a bug where it's not possible to split a sector under certain circumstances, reported by Micky C here: http://forums.duke4.net/topic/1348-mapster32-problems-and-bugs/page__view__findpost__p__138380 Also, don't allow zero in various 'F functions: Resize selection and Global {shade, visibility} divide.

We do this by messing with the GL texture that gets uploaded for CHAINGUN. Since this is implemented on the engine side, the static value for CHAINGUN (2536) is used, and the tile dimensions are compared to 211x55 to have a little confidence that the tile wasn't overridden by a mod. Hack indeed.

Currently, the FPS determination is based on libvpx's vpxdec.c code, which uses the FPS provided in the IVF file in one case, and simply sets it to 30 FPS in the other. For the first case, a "correction" is carried out for something which the comments suggest to originate from other (old?) VPX encoder versions.

When LShift is pressed and the mouse is over a linking sprite (as determined by the tag labeling system), lines are drawn to all other sprites, and pressing [ or ] will cycle these then. False positives and missed sprites are possible. Additional changes: - consider SE 31 and 32's lotag to NOT be linking, since the ACTIVATOR is what matters. The original maps are inconsistent there. - When pressing Alt+[ or Alt+] and there are no corruptions, say so instead of doing [ or ].

The attribute is set per tile from DEF: either texhitscanrange <begintile> <endtile> or tilefromtexture <tile> { ... texhitscan ... } (As a special case, the list may only contain "texhitscan", in which case the texture is not changed.) In passing, do some cleanup for "tilefromtexture" DEF parsing: the list tokens should now be accepted in any order, and errors don't appear in the middle of the list parsing.

Going to extremes to avoid code duplication like the plague, but at least it's great to learn about the whole function environment business.

sizeof(_prlight) differs across compilers, and besides, Polymer lights were not loaded anyway (they're restored live in-game later). The savegame version was not bumped, but only savegames made with builds where sizeof(_prlight)==261 (like synthesis) will stay compatible! Report and helpful debugging information by LeoD.

... and displaying statistics afterwards. It was easier to do it this way than porting stat.lua to C and especially adding more logic to the already spaghetti-like demo playback code.

Instead of having 'noalreadyrefd' as a 'corruptcheck' subcommand. This way, TAB completion can be had.

It's mostly taking over the NASM code, with a couple of changes: - declarations for externals and globals are slightly different - the masm seems to have e.g. "dword ptr [...]" where the nasm has only "dword [...]", though the masm also has a couple of the latter. The "ptr" modifier seems kinda redundant to me, but I added it to every indirection anyway.

Previously, we used them in our builds for sprites, but MSVC builds don't have the ASM ported to MASM, and thus the workaround of ignoring the linking errors was not safe.

Also, add convenience wrapper script findmaps.sh for quickly searching for sprites/walls/sectors satisfying a certain condition in all map files under a given directory.

Requested auto-correction will place such sprites at their sector's first point.

Hendricks found a bug caused by that commit, so this one enables exprimentation with setbrightness() bit 1 behavior.

EDuke32 will exit afterwards.

See the comment in source/osdcmds.c for instructions on its usage.

This makes the splitscreen mod not have a ridiculous view distortion. Such scenes will have no correction for non-square pixels, though.

Specifically, use the elevator's own ceiling z height instead of searching nextsectors with nextsectorneighborz(). This makes maps like L9.map (Spaceport from N64) or DEMOUNT.MAP work. [Note well: work at all, since if it happened to work before, that was pure coincidence.]

Have fun researching Duke3D's hardcoded weirdness!!!

- duke3d.h: comment the timing marcos a bit more - factor out smoothratio calculation - (TICRATE/TICSPERFRAME) --> REALGAMETICSPERSEC

Also, correct some comments made in the demo source made earlier. Oops.

This currently says that MP saving/loading isn't supported, but doesn't really work correctly. Also, properly bound-check the immediate argument to CON's 'save' command and one more ... -> G_HandleAsync().

... and use it in three places. In two of these uses, 1) CON {read,write}arrayfromfile and 2) G_SavePlayer, display an error message if the file name such generated is too long. In the CON commands of 1), also error out if the file couldn't be opened.

This trims four 4k pages of code from the release EDuke32 build and one page from Mapster32.

When this happens, parallaxmodes other than 0 will be unavailable and silently draw as parallaxmode 0. This usually happens with extremely wide resolutions.

We're pulling stuff from math.h even in non-GL builds right now, so adding libc's sin() and atan() doesn't seem like a big deal. In the unlikely event that their accuracy is so bad that the calculated tables don't match the original ones, a warning is issued on little-endian platforms.