What changed in EDuke32, build by build

suboptimal, but at least 'correct' and won't produce the aforementioned corruptions anymore.

nextwalls. (i.e. setting them to -1 on 'corruptcheck tryfix')

can be caused by copying map parts from one map to another (or a new one). The copying system is slightly broken right now....

next{wall,sector} indices instead of using checksectorpointer() so that the nextwalls will be restored exactly as they were (provided that they are copied). Also fix tweaking the sectnums of sprites.

would break out of the 2D mode loop when splitting a sector would exceed limits.

- Don't crash when sector joining fails under certain circumstances. - Increase the point lock (Manhattan) distance from 1/16th to 1/8th of the grid square length, making it easier to snap to vertices not lying at the grid points with grid lock on - When drawing walls, don't snap to any of them except the first drawn

The main change consist of adding a key press (and release) callback whose only purpose is to be used from m32script as EVENT_KEYPRESS. When entering that event, the RETURN variable will be set to the keystatus code of the key, and whether it was pressed or released can be checked by looking at keystatus[] at that code (ifholdkey and ifhitkey do this). The purpose of this, then, is to be able to remap keys in a more general (and complicated) fashion than is possible with the mapster32.cfg 'remap' option. Various other additions build around this central one: - add an example EVENT_KEYPRESS to a.m32, among other things emulating the keypad arrows with Alt-<normal arrows> for notebook convenience; disabled initially - a.m32: set 'owner' with Alt-KP2: now Alt-Shift-KP2, because of collision with the above - new m32script command: setkey <keycode>, setting keystatus[<keycode>] to 1 (note: may be restricted to use in EVENT_KEYPRESS only in the future) - fix indexing an m32script array with a defined label, there used to be a 'not a gamevar' error instead - add the following constant labels for some key codes: KEY_SCROLL, KEY_F1 .. KEY_F12

with no highlighted sectors; and when entering 3D mode, even if there are highlighted sectors. This should have almost no effect, but I find it cleaner that way. - Check map for corruption every time an editing change is done. This was accidentally disabled when commenting out the undo code (which I've yet to debug).

selector. This could lead to a crash when OpenGL wasn't initialized before.

memory map.

(lazy_tileselector=1 in mapster32.cfg). We're drawing tiles one by one, so glDrawBuffer(GL_FRONT_AND_BACK) is our friend.

Now, if more than one sectors are affected, always move them by the same amount. That is, if one of them would be sticking against the other side, don't move the rest. Another change consists of determining the z delta first, and only then moving the sprites by that amount. This fixes the problem where you'd e.g. raise a 'floor door' against the ceiling, and the effector sprites would be raised one time too much, preventing them from being lowered the next time.

- new mapster32.cfg and OSD variable 'fixmaponsave_sprites', telling the editor whether to 'fix' the sprite sectnums on saving and entering 3D mode. Note that a) sprite sectnums are never fixed when 'script_expertmode' is enabled, as before, and b) sprites that have out-of-bounds sectnums are still fixed if a proper sector is found - if saving and some sprite sectnums have thus been tweaked, inform the mapper on the status line and print the changes in the OSD - fix update issue similar to an earlier one: when 'saving as', the astub.c- based file name is now updated too, so saving with Ctrl-S now saves into the one save with 'save as' (and not the old one) - don't attempt to recheck wall pointers from scratch (when saving and running with -check) if it's a TROR map

This was meant for debugging only.

Hopefully this fixes the periodic pausing/unpausing that a few people have been experiencing. Also fix build with GCC 3.

the 'optimize' function attribute if LTO is enabled.

with RAND_MAX > 32767 (everything except Windows?). The 'displayrand' command now returns values from 0 to 32767 inclusive, across all platforms.

This one could have only happened with TROR maps, I think.

last one + this one: A couple of tweaks against accidental overwriting of maps. - first, fix a bug where the map name wasn't reset to 'newboard.map' when starting a new map - When saving with Ctrl-S, query the user for confirmation and also show the file name where the map will be written - when going into the ESC-menu, print the file name where the map will be written on pressing 'S' above the '(S)ave' text

- first, fix a bug where

allowed circle-walls started on the unconstrained _other_ side of a constrained wall. Also fix a potential invalid wall access when inserting a point (pretty serious, that!)

also for make-circle (C, SPACE). There's still a TROR corruption happening probably when inserting on constrained walls, but I've yet to get behind the real cause.

overheadeditor() by allocating temp variables in the blocks where they are needed.

HOME or END in the user map selector. Now it's only one.

- fix arg checking in checkdefs.sh - some tilenum and quote ID validation in the CON interpreter - G_DrawDigiNum and friends: eliminate redundant strlen calls

ATI cards. From the time of OpenGL initialization, gamma lookup in classic/fullscreen will be done in software. Before that, always do a setgamma() after setting the palette, since this is what resets the HW gamma. However, this may lead to unappealing artifacts with portions of the scene being sent to the screen with different gammas.

fix: http://forums.duke4.net/topic/4907-laserline-crash-bug/

ceilings or floors. In such cases, you're not squished unconditionally (instead of fetching the ceiling or floor height of the neighbor sector), but TROR isn't meant for small-scale RoR anyway.

polymer_addlight(). I have no idea whether it's the 'right' thing, but it fixes this: Conditional jump or move depends on uninitialised value(s) at polymer_updatelights (polymer.c:5090) by polymer_drawrooms (polymer.c:938) . . . Uninitialised value was created by a stack allocation at loadmaphack (engine.c:9482) Fix another uninitialized access when rendering jpegs.

This fixes a crash when loading a map afterwards. Tweak a few debugging messages and some whitespace.

This also fixes a warning when building for Windows.

My choice of solution is simply to add an extra set of values duplicating the previous five because doing so would definitely show the user no changes. I could have tinkered with the messy loop where the out-of-bounds references are made but there is no guarantee I could have succeeded or kept compatibility.

Polymer has a hack that snaps horiz values of spotlights between 90 and 110 to 90 and 110 to avoid triggering aliasing artifacts with perfectly horizontal spotlights. Propagate that change all the way to the spotlight SE sprite so that the code won't think that the horiz is always different from the light and mark it invalid each frame.

We need to Y-invert the projection texcoords when sampling from the lightmap.