* add global autoload directories to search before local ones
Fixes#331
* fix WOOFDATADIR path
* remove debug puts()
* use pointer progression instead of array indexing
* replace DOOMDATADIR with WOOFDATADIR
* remove obsolete check for autoload_paths being NULL
PrepareAutoloadPaths() is now only called once before any of the
functions calling GetAutoloadDir() is called.
* add libtextscreen
* add doomkeys.h
* fix format string warnings
* delete all files unnecessary for ENDOOM
* add ENDOOM support
* show ENDOOM screen in the same window as the game
* add PWADs only option, add comments
* change PWADs->PWAD
We already properly save window dimensions in the window_width
and window_height variables. Still allow to set a scale factor
from the command line, though.
* check for pusher source thing
* convert pusher source thing pointers into indices
* fix gcc build
* fix type cast
* try to simplify type cast
* update savegame version
* remove bump of savegame version
* add pusher->source check
* add pusher type check
* port exclusive fullscreen over from Choco/Crispy
Fixes#334
* fix disabled menu item
* if fullscreen_width or fullscreen_height are set, default to fullscreen
* add Chex Quest support
* more changes for Chex Quest support
* fix misleading indentation warning
* fix HUSTR_*
* fix indentation
* add more IWADs to standard_iwads[]
* don't autoload from doom-all
Fixes#301
Short analysis: Usually, the colfunc() pointer is reset to
R_DrawColumn() in R_DrawVisSprite() when the player sprites are
rendered via R_DrawPSprite() in R_DrawPlayerSprites() as the last step
in R_DrawMasked().
However, if you bob your 1px wide weapon sprite out of view,
R_DrawPSprite() returns early and the weapon sprite's vissprite is
never rendered, thus the pointer is not reset. That's why the glitch
immediately disappeared when switching to a regular weapon sprite such
as the Chainsaw. This also explains why the glitch never became
apparent in widescreen mode.
Actually, removing the TRANMAP lump or forcing to regenerate it did
*not* fix the issue. It was still there but a lot less visible, since
translucent textures were drawn on translucent textures which were
drawn on the black void - the TRANMAP just helped to make the glitch
undeniable, together with the player sprite that actually triggered
it.
Apparently, the case that I attempted to fix earlier, i.e. that the
TRANMAP lump gets marked as purgeable after being used as a
translucency table for a mid-texture, is already been taken care of
in P_LoadSideDefs2().
