What changed in EDuke32, build by build

The scrollwheel is unique among PC input because it has no innate "hold length". Previously, the layers gave the mousewheel a fake hold length to allow the not-necessarily-synchronous game/editor code to pick up the input before the layers marked it as "no longer pressed". This passed under Windows, but it didn't slide under SDL. Besides the two problems listed above, it also potentially limited the rate of weapon selection, where scrolling too fast would not register every clicks. [Unrelatedly, this is still the case when you scroll faster than the game's own tickrate, but addressing that would require rewriting input handling to go through a list of "events" for each tic instead of looking at overall pressed/unpressed states.]

Exposed by this snippet from a.m32: getnumber256 .owner "OWNER (projection picnum): " -MAXTILES Now, Alt+KP2 works as expected in 3D mode.

This requires enabling the same workaround as for Linux. Maybe it's not system-dependent at all.

This generally fixes demo playback. Before, tilesizx[]/tilesizy[] were written into twice as many bytes as needed. Now, don't do that at all.

I was checking for GCC >= 4.7, while Clangs pretends to be GCC 4.2. Use a feature test macro instead. The comment I made in r4161 regarding GCC vs. Clang code was wrong. Now, Clang generates slightly faster code for these cases (solid and masked 4-pixel wide vlines).

By detecting them in the SDL_KEYDOWN events. This list is getting a bit ridiculous...

This fixes some init and update anomalies: before, - init would always be the graphical mode (0), but writing merely "osdtextmode" would switch it - osdtextmode would not get saved to the cfg

This renders tweaks like r4122 unnecessary. Also, note a "bug" with the program generating that C code.

This was caused by mismatched for types mapstate_t's animateptr[] and the global one (int32_t vs. int32_t *). Bump BYTEVERSION.

This fixes ESC in certain situations such as the editor map selection menu.

This fixes a potential crash caused by violating the expected invariant sprite[g_player[player_index].ps->i].yvel == player_index otherwise.

- Add SDL scancode -> our key code map for SDL_SCANCODE_APOSTROPHE - Remove duplicate map for SDL_SCANCODE_PAUSE

DONT_BUILD.

The leak happened because a struct was hashed that had uninitialized bytes in padding inserted by the compiler. The hash string in now constructed as concatenation of three CRC32s as 8-byte hex strings, i.e. the individual CRC32s are padded with leading zeros. Note to users: because of the hash change, it's sensible to delete the 'textures' and 'textures.cache' files.

References: - r3742 - r4038 (fixing savegame screenshots, but introducing the now fixed bug)

That change confounded character-based input with e.g. HUD control under certain circumstances, see http://forums.duke4.net/topic/6845-eduke32-savegame-annoyances/ Also, BUILD_LUNATIC ... just for the hit.sect -> hit.sector change.

Variables at global scope which share a name tend to actually be the same variable. Not good when you pass such a variable to function that immediately returns if the passed parameter (the variable) equals said variable (itself).