Cosa è cambiato in EDuke32, build per build

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

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

This includes a complete Windows header and library refresh, including the addition of 64-bit compiled libs: *libogg 1.3.0 *libvorbis 1.3.3 *zlib 1.2.7 *libpng 1.5.13 *libvpx 9a3de881c0e681ba1a79a166a86308bbc84b4acd *SDL_mixer 1.2.12 (for RENDERTYPE=SDL) *DirectX import libraries: dsound and dxguid (now included) To build in 64-bit, you essentially need MinGW's MSYS (but not MinGW itself) and MinGW-w64 at the top of your PATH. The target is automatically detected using `$(CC) -dumpmachine`. The EDukeWiki will get detailed instrucitons. All compiler and linker warnings when building in 64-bit mode have been fixed. Remaining 64-bit to-do: - The ebacktrace dll does not build under 64-bit. It uses code specific to the format of 32-bit executables and will have to be ported to work with 64-bit executables. A future 64-bit version will be named ebacktrace1-64.dll. - RENDERTYPE=SDL crashes in SDL_mixer's Mix_Linked_Version(). - DirectInput gives an error and does not function. This only affects joysticks, and the error never happens without any plugged in. - Port the classic renderer ASM to 64-bit. (Just kidding, this is way out of my league.) This commit includes a fair bit of Makefile development spanning all platforms, including simplifying the SDLCONFIG code, fixing build on Mac OS X (thanks rhoenie!), globally factoring Apple brew/port inclusion, enforcing that all -L come before all -l, and ensuring that $(shell ) is always :='d. In addition, I have resurrected the old GCC_MAJOR and GCC_MINOR detection using `$(CC) -dumpversion`, but I have made it failsafe in case the command fails or the version is manually specified. I have applied this new fine-grained detection where applicable, including allowing LTO, and restraining -W's to versions that support them.

Set up the use of {Windows,Apple}/{include,lib} regardless of feature toggles in Makefile.common using $(abspath ) in reference to the directory Makefile.common is in. Add the three DirectX headers that are actually used to the repo. (from: http://alleg.sourceforge.net/files/dx9mgw.zip) Since current MinGW versions include DirectX libs (for dynamic linking), remove "-L$(DXROOT)/lib". The DirectX headers are no longer a separate dependency for building. Add $(SDLROOT_OVERRIDE). $(SDLROOT) only functions for Windows and Mac OS X. Factor handling of $(DXROOT_OVERRIDE) and $(SDLROOT_OVERRIDE) into Makefile.shared using $(abspath ).

Also, fix deficient logic in Gv_Free and Gv_Clear (both M32 and CON) so that gamevar and gamearray erasure results are (closer to) correct, and so that the game does not crash when system arrays are accessed from CON because they all have been nulled.

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