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

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.

Sub-tokens: "mapfile", "maptitle", "mapmd4", "mhkfile" http://forums.duke4.net/topic/6070-user-map-maphacks-eduke32-feature-request/

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

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.

It was caused by the definition of c_dfDIJoystick using literal 24 and 16 values in place of sizeof(DIDATAFORMAT) and sizeof(DIOBJECTDATAFORMAT), which include pointers. On 64-bit, the values end up being 32 and 24, causing a discrepancy in which DIERR_INVALIDPARAM was thrown. https://gitorious.org/0xdroid/external_libsdl-12/commit/1b1e05db06edcbe64599c6a5ad703795e0e02acb/diffs

- Updated to use StackWalk64 function call, requiring some addition of headers from MinGW-w64 to compile with MinGW. - Code added to support 64-bit executables: functionality added and one warning fixed. - New DLL binaries compiled using i686-MinGW-w64 and x86_64-MinGW-w64. (Oddly, the DLL built with MinGW is 5 MB while MinGW-w64's is 1 MB.)

to facilitate compatibility with stuff like Dukester X years ago