What changed in EDuke32, build by build

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.

most problems where sprites appear to be drawn through walls.

This way, crashlogs will really be appended. Additionally, print a time at the end of each backtrace. winlayer.c: load ebacktrace1.dll instead of the old one Makefile.common: when building with DEBUGANYWAY=1, don't omit frame pointers This will let us get a stack trace for crashes with the release build code.

http://forums.duke4.net/topic/1348-mapster32-problems-and-bugs/page__st__480 (I think, didn't test it)