Cosa è cambiato in EDuke32, build per build

In the normal game, these arrays are conceptually [MAX_WEAPONS][MAXPLAYERS], allocated as CON per-player gamevars (e.g. WEAPONx_WORKSLIKE). For Lunatic, they are replaced with weapondata_t g_playerWeapon[MAXPLAYERS][MAX_WEAPONS].

Specifically, have a weapondata_t type mimicking the aplWeapon* arrays. Keep a list weapondefaults[] which undergoes some static->dynamic tweaks and then makes its way to the WEAPONx_XXX per-player gamevars.

- Rewrite the "clear background" routine in a no-brainer way instead of juggling around with rotatesprite(). Make it common to game+editor. Expose glRectd to glbuild. - Don't stop OSD text line drawing when encountering a non-printable char. Instead, treat it as space. - In OSD_SetTextMode(), don't use swaplong (which really swaps 32-bit ints) to swap pointers. Write an analogous "swapptr" instead. - When changing from/to OSD, don't inject a pause key. This *might* have been the cause of the reported pausing problems. - clean up the code... (Yes, this commit throws together too much stuff. I suck sometimes. :P)

Rotation-fixing happens for a couple of hard-coded statnums that presumably never move (DEFAULT, STANDABLE, FX, FALLER, LIGHT), but for actors it wouldn't make sense since the common case is that they do move. For this reason, bit 4 was introduced in r1934. The position of such useractors will not diverge due to error roundoff accumulation in rotating sectors (SE0, train).

Unconditionally enabled, but useful for comparing the behavior of the 1-column vline functions against the 2- or 4-column ones.

The former is really only a workaround. Walls/vertical sprites/pskies with ysize 512 (and presumably greater, but this was not tested) are rendered with one shade higher at the borders (1 pixel vlines) because of a certain assumption in the ASM (see comments there). With very dark shades, the palookup[] buffer is accessed oob. We simply allocate 256 bytes more at the end for each. The latter is only for CLASSIC_NONPOW2_YSIZE_WALLS builds, which is not enabled yet. It seems to matter only for the uncommon case where the such pskies repeat in the height. A 1680x1050 window fully covered with such a sky is then rendered at about 60/85 the FPS for me (mostly due to not using the 4 pixel vline routines), so it may be leaning a bit too much on the side of correctness. A compilation switch DEBUG_TILESIZY_512 is introduced in engine.c for demonstration purposes.

- If aiming at a swapped bottom wall, display "Wall <wallnum> -> <otherwallnum>" - highlight pic, shade, pal, cstat in yellow then - in printext256, accept at most 3 digits for the color format string (e.g. ^123)

That is, everything concerning orientation. Previously, it was wrongly the bitwise NOT of these bits that got taken over. In particular, if bit 2 (swap bottom walls) would get pasted, ridiculousness could ensue.

The new "r_usenewshading 2" mode could darken these otherwise.

Implemented using GL_LINEAR fog. The only source of difference (besides the obvious indexed vs. true color) should now be the distance constant, which still had to be determined experimentally. Polymer implements this mode in its fog fragment program part. Parallaxed skies are always drawn with full visibility, I'm not sure if there are any maps that expect otherwise. Also, accidentally committed: factor out initialization code from polymost_printext256() into gen_font_glyph_tex(), small game.c changes.

This prevents computing a shift value outside of [0..31].

This fixes 2nd and following rotatesprite calls drawing differently from the first in a context with custom set-up aspect, as reported by Lezing here: http://forums.duke4.net/topic/775-eduke32-20-and-polymer/page__view__findpost__p__143090 Also, back up and restore the aspect state across EVENT_DISPLAYREST.

Bump BYTEVERSION.

Disabling netcode compilation can be interesting on memory-constrained systems, or those that have no means of accessing the network anyway. Note: I'm OK with maintaining this myself, i.e. it's fine if netcode dev breaks compilation with NETCODE=0.

... instead of switch/case-ing them in A_CheckEnemyTile(). Because this requires bumping BYTEVERSION, we also get rid of the excess trailing bytes in the save game's "rest" data. (See r3052.)

- more codegen - make more members const, some char unsigned - fix some "geom" metamethods - '^' operator

1) see if we actually received anything (if http://eduke32.sourceforge.net/VERSION is unavailable, this returns now instead of continuing with nonsensical data) 2) check if we're getting a token from strtok()

The attribute is set per tile from DEF: either nofullbrightrange <begintile> <endtile> or tilefromtexture <tile> { ... nofullbright ... } As a special case, the list may only contain "nofullbright", in which case the texture is not changed. (This is analogous to "texhitscan".) Example: // make piggy's eyes fullbright red only when it fires the shotgun nofullbrightrange 2000 2034 nofullbrightrange 2040 2049 nofullbrightrange 2055 2061

The two uses are from hitscan and neartag. The functionality is reproduced exactly (assuming I made no mistake), down to different distance checking (<= vs. <).