What changed in EDuke32, build by build

- enclose glbuild.h in #idndef ... sentinels - engine.c: remove unused variable 'pageoffset', make 'lastx' static - formatting

This may fix compilation for optimized builds with GCC or clang where the compiler would otherwise decide that those symbols are unused.

If enabled, this makes the following arrays be allocated statically: spriteext, spritesmooth, sector, wall, sprite, tsprite, while necessarily disabling the clipshape feature (because it relies on setting sector/wall to different malloc'd block temporarily). To compile, pass DEBUGANYWAY=1 in addition to RELEASE=0 to 'make', and it's really only useful with CC=clang, of course.

Ideally, we would also warn when setting WEAPONx_SHOOTS to negative values, but we'd have to intercept CON's setvar's and it wouldn't be pretty.

I'm decreasing EXTRATILES because I feel that it's way overcommitted. It's the max number of model-tiles that have their own skin for a certain palette, like the slimer egg in the HRP.

- fix one bound-checking line - rewrite two lines in astub.c to potentially not overflow an int16 - make tiletovox[] an array of int16's

- hud_orientation now uses proper bitwise operations - clean up whitespace

Always malloc that buffer. This allows us to remove suckcache() from cache1d.c, which I believe to be buggy (see comments in the source).

- 'whitecol' was defined in the engine and in build.c, use only the engine one - make cachesize, artsize, artversion static in engine.c - undo some formatting havoc presumably done by astyle

It is likely that this is the value it used to have at some point, because the MAXTILEFILES macro equals 256 and is as old as the Duke3D source. loadpics() now refuses to load an ART file with localtilestart or localtileend out of bounds, or if localtileend<=localtilestart (i.e. no tiles in ART file, or nonsense). Also, on 'invalid art file version', continue instead of returning. Note: this does not increase the maximum number of tiles, which is still 15360, it only gives a bit more freedom to arrange them (well, into more art files). Also, I don't see what anyone keeps off from packing any number of tiles (from 1 to 15360) into an art file. Old EDITART limits?

The cause was a combination of many factors. First, Polymer requires the start-drawing position to be inside the sector to draw (deviations lead to incorrect drawing). This was violated by the game, because it interpolated the current and next tic position without updating the sectnum, leading to inconsistencies especially when passing through narrow sectors. Polymer worked around it by doing an updatesector() each frame, however this works poorly for maps with overlapping geometry such as SoS or RoR. The solution to this is to add a new engine function, updatesector_onlynextwalls(), which searches the sectors (via nextsector) in breadth-first fashion instead of from 0 to numsectors-1, like updatesector does when it fails for the *immediate* nextwall neighbors. Internally, the breadt-first search helpers are moved into the engine.

so try and steal it back"), prevent calling IDirectDrawSurface_SetPalette() with NULL arguments, causing a crash. It's happened for me on Vista, when initially changing from 8-bit to 32-bit mode.

I didn't have much success in finding bugs using it, but it works out-of-the-box on my setup, so it may be useful in the future.

The second one is passed to the 'mouseb' variable, but the game currently can't map it since ud.config.MouseFunctions[] would have to be enlarged, breaking savegame compatibility. Works both for the Windows and SDL layers. For the latter, instead of using the SDL_BUTTON_X1/X2 macro constants, I'm using 8 and 9, since that is what SDL (and incidentally or not, xev) gives me for those buttons.

It turns out that with model interpolation, out-of-bounds frame numbers may be generated with thinned out models, so disable it until I can sort out what's wrong with it. Also, minor code cleanup.

this in "(unsigned)i < bound" fashion.

E.g. this should work correctly now: // FLY_BY, PIPEBOMB_EXPLODE, OCTA_DYING animsounds logo { 1 244 64 14 64 144 }

let it hang around causing trouble later on; delete it right now and inform the user. Add a couple of 'static's to some functions and file scope data in mdsprite.c

the SE ones douple, triple, ... after each save. Maphack lights are reloaded with polymer_resetlights() (though I've had them disappearing after load, I couldn't reproduce it afterwards). - in debugging builds, print a message when polymer_resetlight is called on a nonexistent one. The problem is not so much the call itself (it's guarded), but the fact that resources on the caller side may not have been freed if it thinks that those lights do in fact exist. Right now, it's not the case though. - add 'loaded map hack' messages after some other successful loadmaphack calls

crashes. Usually, after loading a game, some wall tiles are tweaked depending on whether adult mode is enabled or not. If it's not, those wall picnums are replaced with blank or broken screens. If it is, they are restored from the wall's .extra member. Apparently though, Mapster32 leaves some .extra members floating around even after deleting a TROR nextwall link (it's used as the 'lower wall index'). Because MAXWALLS is greater than MAXTILES, this may produce out-of-bounds accesses and corrupt memory (besides setting wall tilenums to nonsensical values) later in the game. Other than that, the change only affects loading savegames created with adult mode OFF. Kinky TV screenies simply won't be restored then.

check one 'if' down since mirrors are only created when the condition holds

JPEG decoder (unearthed by valgrind).

Resetting the gamevars might produce inconsistencies between an earlier loaded game (for example, if it was saved with different/earlier CON code), and worst of all, the gamevars that reference C variables might be overwritten (i.e. the addresses to those variable, which is very bad!).

- Execute VM_ScriptInfo() when DNDEBUG is used.

instead of -1. Setting is still only through 'setgamepalette'.

'frequently' isn't such a good idea. Assume an actor constantly changes the palette to some value and you're attacked by a newbeast at the same time. Then the pain tinting would be reset each time the actor's code is run. This commit adds a new flag 16 to setbrightness(), meaning "don't reset the fade tinting". Its only use right now is from CON's setgamepalette command (and there, always). The change is done in the engine and thus affects all platforms.

mainly. Also remove setvgapalette() from source.

certain situations (mostly cutscenes etc). This commit removes bit 1 from all flags that make it to setbrightness, the meaning of which is "don't actually update the palette". I have no idea what it was for and since the corresponding P_SetGamePalette() calls were from places like the mentioned cutscenes, I don't think it matters performance-wise.

This is in the similar vein as the set-palette deferring and it's this that fixes the low FPS in the radioactively contaminated area in AMC TC: Megabase (since setgamma() is called from setbrightness()). Again, update issues might be expected, but changing focus between EDuke32 and the desktop and back seems to restore the gamma settings properly on Kubuntu. Looks like X (or whatever above handles this stuff) maintains it on a per-application basis.

CON code sometimes uses 'setgamepalette' from withing actors, which is a bit too frequent. Deferring the actual palette updating means that multiple requests in between two screen redraws are coalesced into one, which is desirable for performance reasons and for the reduction of 'tearing' artefacts (but not prevention, since the drawing isn't synced to the screen refresh rate with vsync off). (Did-not-)update issues might be introduced. Windows isn't touched because - I expect it to be more brittle, especially in light of the ATI HW gamma problems. - I haven't tested whether the particular performance penalty that lead to this change ('gas' in AMC TC) exists there too

instead of shorts. This fixes their values' overflow in AMC TC megabase and probably a couple of other large maps.