Cosa è cambiato in EDuke32, build per build

Windows batch file: for /r %%G in (*.a) do svn propset svn:mime-type application/octet-stream "%%~G" for /r %%G in (*.lib) do svn propset svn:mime-type application/octet-stream "%%~G" for /r %%G in (*.dll) do svn propset svn:mime-type application/x-msdownload "%%~G" for /r %%G in (*.ico) do svn propset svn:mime-type image/vnd.microsoft.icon "%%~G" for /r %%G in (*.icns) do svn propset svn:mime-type image/icns "%%~G" for /r %%G in (*.bmp) do svn propset svn:mime-type image/bmp "%%~G" for /r %%G in (*.png) do svn propset svn:mime-type image/png "%%~G" for /r %%G in (*.xcf) do svn propset svn:mime-type image/x-xcf "%%~G" for /r %%G in (*.psd) do svn propset svn:mime-type image/vnd.adobe.photoshop "%%~G" for /r %%G in (*.nib) do svn propset svn:mime-type application/octet-stream "%%~G" for /r %%G in (*.map) do svn propset svn:mime-type application/octet-stream "%%~G" svn propset -R svn:mime-type application/octet-stream polymer/eduke32/Apple/lib svn propset -R svn:mime-type application/octet-stream polymer/eduke32/Windows/lib/32 svn propset -R svn:mime-type application/octet-stream polymer/eduke32/Windows/lib/64 svn propset -R svn:mime-type application/octet-stream polymer/eduke32/source/jaudiolib/third-party/Apple/lib svn propset -R svn:mime-type application/octet-stream polymer/eduke32/source/jaudiolib/third-party/Windows/lib/32 svn propset -R svn:mime-type application/octet-stream polymer/eduke32/source/jaudiolib/third-party/Windows/lib/64

FLAC source from git commit 0920bc1ffb07f038b317e7e8056509fe0e4b680e, patched by me. Windows libFLAC.a built using i686-MinGW-w64 and x86_64-MinGW-w64. HUGE thanks to rhoenie for building the Mac fat library (ppc, i686, x86_86).

* Renamed source/jaudiolib/third-party/mingw32 to source/jaudiolib/third-party/Windows. * Moved source/jaudiolib/third-party/Windows/include to source/jaudiolib/third-party/common/include to use both on Windows and Apple. * Deleted Apple/lib/include/{ogg,vorbis}/, see previous point. * Deleted Apple/lib/libvorbisenc.a, 6MB saved. * Moved Apple/lib/lib{ogg,vorbis,vorbisfile}.a to source/jaudiolib/third-party/Apple/lib, where they belong. * Moved source files in Apple/ to source/, where they belong. (SDLMain.[mh] stay.) * Deleted source/jaudiolib/third-party/{ogg,vorbis}.framework, not used any more. * Renamed "StartupWinController*" to "startosx*".

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.

And rewrite the original functions as wrappers around these.

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)

Annulla

705cc72

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.