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.]

While we're rearranging files, ensure all SVN mime-types are set correctly.

I updated the help windows to prefer these variants because they are superior to the -xSquished versions. Also, factor out the command-line processing code for the above, plus con/def modules and clipmaps.

DONT_BUILD.

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).

NOTE TO TEAM MEMBERS: Please review this, as I am not sure what is actually intended here.

- Don't print osd.szCSDVersion when it is empty, preventing an extra space between the OS name and version number. (An example of what this field holds is "Service Pack 1".) - Under SDL, allow the "console" edit field to repaint after "OK" is clicked. Important when a long def file is loading.

Unfortunately, SDL2 does not (yet?) provide a Yes/No box for wm_ynbox().

Cognitively, so much time has passed that these unused variables would offer little help indicating the roadmap for networking. In any case, I have taken care only to comment rather than remove anything that is more than just a throwaway loop counter. If this commit inconveniences anyone in any way, please contact me personally and I will make it right.

To build with SDL2: make RENDERTYPE=SDL SDL_TARGET=2

We have to work around namespace pollution in <sys/stat.h>.

- Allow xoffset and yoffset to modified independently of a tile definition, much like texhitscan and nofullbright. (Both still default to zero when a tile is specified, to keep current behavior, and because it makes sense.) - Add actual detection of the "nofullbright" keyword, which appears to have been overlooked in r3230. - Internal: Eliminate the need for one int32_t by condensing two variables into "flags".

The commit revises the definition of qstrdim when TEXT_[XY]OFFSETZERO are used. With these flags, the offsets the user specifies are now the only dimensions the function cares about in terms of tile placement, so depending on the difference between the offset(s) and the size of the final tile, it may be slightly more or less than the dimensions actually displayed on the screen because tile size is never taken into account. (For example, if your font is nominally 9x7 like the Duke bluefont and you use a TEXT_XOFFSETZERO of 5 with a string five characters long, the total x dimension will be 25 even though the last character will overhang that amount by four pixels. If you use a TEXT_XOFFSETZERO of 12 with the same string, the total x width will be 60 even though there will be three pixels of empty space on the right edge.) This change was made because assigning text an arbitrary constant width in general implies an intent to keep character positions constant even with a variable width font, but returning the visible span of pixels on the screen that the tiles cover would have caused the string to move when alignment options other than the top-left were used. In other words, you can now safely use TEXT_[XY]OFFSETZERO with the alignment options and the text won't jiggle. Also, with TEXT_GAMETEXTNUMHACK, numerals are now effectively TEXT_XOFFSETZERO text that respect the above paragraph, so number count displays can look nice with alignment options too. Having to modify the extent/offset code makes me realize that I'm not quite happy with its structure because it gets tangled juggling different concepts like character width, X offset, and spacing, and how they relate when the line wraps or in terms of the final size. Fortunately, it produces correct results as far as I know, and it's not necessarily ugly, just hard to understand. Handle with care.

G_PrintGameText(), minitext_(), G_DrawTXDigiNumZ(), and menutext_() now wrap G_ScreenText(). G_GameTextLen() now wraps G_ScreenTextSize(). G_DrawDigiNum_() now wraps G_DrawTXDigiNumZ().

It should be transparent even with the meter disabled.

[1] http://forums.duke4.net/topic/2961-paper-cuts-minor-bugs-and-annoyances/page__view__findpost__p__153060

Let me know if this breaks any mods that have #2462 with an x-dimension other than 320.

(Note: We are still vulnerable to crashes here (and likely in other places), but you have (4096-16) extra characters to work with. We should consider replacing many uses of Bsprintf with Bsnprintf.)