-faketilesiz[MAXTILES] removed in favor of simple faketile[(MAXTILES+7)>>3] bitfield
-h_xsize/h_ysize (tile size overrides from .def) are now uint16_t instead of int32_t
-hudmem[2][MAXTILES] removed in favor of adding a hudmem ptr to mdmodel_t
-tilefromtexture performance improvements
-more tsectortype/twalltype usage in various engine functions that read but never write
-continued Polymost cleanups and refactors. Please report any odd rendering errors.
git-svn-id: https://svn.eduke32.com/eduke32@5079 1a8010ca-5511-0410-912e-c29ae57300e0
-lots of stylistic rewrites
-further improvements to anti-fighting code for wall and floor sprites (introduces three new cvars, r_wspr_offset, r_wspr_offset_variance, and r_fspr_offset)
-fixed brief HOM when traversing through a one-way masked wall
-seldomly used "alphahack" feature for hightile textures now represents alpha cutoff internally as a single byte instead of a float
-fixes a handful of issues where geometry failed to draw at certain coordinates from certain angles in certain resolutions
-renames a couple of cvars
git-svn-id: https://svn.eduke32.com/eduke32@5075 1a8010ca-5511-0410-912e-c29ae57300e0
The latter means that running perpendicular thin sector is handled better
if there are e.g. TROR sectors in the same x/y space.
git-svn-id: https://svn.eduke32.com/eduke32@5024 1a8010ca-5511-0410-912e-c29ae57300e0
replacements for the first handful of palette lookups) w8th superior
"luma" method. DONT_BUILD.
git-svn-id: https://svn.eduke32.com/eduke32@4889 1a8010ca-5511-0410-912e-c29ae57300e0
Also for polymost_scansector(). These were likely of little consequence
because collection in scansector() is the exception than the rule (see
added comments), and because the redundant drawwalls() would find the
x range done the second and following times.
Also, add a bound check for sectorborder[] (the limit was probably rarely
hit in practice, but the check is mandatory nontheless) and add functions
printscans() and printbunches() in the DEBUGGINGAIDS=2 build.
git-svn-id: https://svn.eduke32.com/eduke32@4877 1a8010ca-5511-0410-912e-c29ae57300e0
- At a given time, at most one viewscreen may display TILE_VIEWSCR, namely
that one which is g_curViewscreen
- sync kinds of distance to compare against VIEWSCREEN_ACTIVE_DISTANCE (was
Manhattan vs. dist(), now both the latter)
- fix resetting to VIEWSCREEN tile when player is greater from it than that
distance. When the player is closer to it again, it is *not* reset to
TILE_VIEWSCR.
- more sync'd g_curViewscreen and sprite[i].yvel (for 'i' being the viewscreen
sprite)
Note: in a multiplayer context, this needs to be thought about once more.
git-svn-id: https://svn.eduke32.com/eduke32@4843 1a8010ca-5511-0410-912e-c29ae57300e0
So that stack traces can be gotten with optimized DEBUGANYWAY builds, e.g. for
Linux's 'perf' --> flame graphs. DONT_BUILD.
git-svn-id: https://svn.eduke32.com/eduke32@4817 1a8010ca-5511-0410-912e-c29ae57300e0
When that mode is enabled (see below for caveats), wall textures that have a
non-power-of-two height (call it 'h') will be modified to look like in classic:
Let 'H' be the next power of two greater than 'h'. The texture will be uploaded
with height 'H', made up from 'h' hlines of the original texture, followed by
'H'-'h' first hlines of the same.
No panning "corrections" will take place. The mode is disabled by default.
Caveats/notes:
* the mode requires that r_hightile is disabled
* it is not implemented in Polymer
* in the Lunatic build, it is ineffective when a VX map is loaded, as those
display walls with NPOT height textures correctly
git-svn-id: https://svn.eduke32.com/eduke32@4498 1a8010ca-5511-0410-912e-c29ae57300e0
... and cull code that is dead with the X*alloc() versions since they never
return NULL on requesting memory.
Use something like
git grep '[^Xx]\(m\|c\|re\)alloc *('
and
git grep '[^Xx]strdup *('
to see places where I left the B*alloc() calls intact.
BUILD_LUNATIC.
git-svn-id: https://svn.eduke32.com/eduke32@4491 1a8010ca-5511-0410-912e-c29ae57300e0
- in mdloadskin() and gloadtile_hi(), use new function check_nonpow2()
(bit-twiddling) instead of loop
- Replace a couple of missed literals with CACHEAD_* enum labels
git-svn-id: https://svn.eduke32.com/eduke32@4488 1a8010ca-5511-0410-912e-c29ae57300e0
Note: in polymer.c, this was buggy (but harmless) because .r is a char:
if ((uint32_t)hictinting[MAXPALOOKUPS-1].r & 0xFFFFFF00) != 0xFFFFFF00)
git-svn-id: https://svn.eduke32.com/eduke32@4487 1a8010ca-5511-0410-912e-c29ae57300e0
Specifically, the handling of one-way walls ([1] in Mapster32) was slightly
different.
git-svn-id: https://svn.eduke32.com/eduke32@4484 1a8010ca-5511-0410-912e-c29ae57300e0
This mode does not take a sector's visibility values into account for uniform
darkening of a texture. It is more faithful to classic with respect to
fog/visibility *distances*, but may be less so as far as the "tint" of the
texture due to visibility attenuation is concerned.
git-svn-id: https://svn.eduke32.com/eduke32@4459 1a8010ca-5511-0410-912e-c29ae57300e0
The overall situation is thus as follows:
- in C and from Lua, that member is called 'fogpal'
- In CON (both C-CON and LunaCON), it's 'fogpal' with 'alignto' being an alias;
'filler' wasn't available before, either.
- In m32script, it's 'fogpal' or 'alignto' ('filler' is not available any more)
git-svn-id: https://svn.eduke32.com/eduke32@4416 1a8010ca-5511-0410-912e-c29ae57300e0
That is, if that member has a nonzero value, that one is taken for the color of
the GL fog instead of (most of the time) sector[].floorpal. "Sky sectors", that
is, skyboxes or simply parallaxed floors/ceilings are *not* handled.
git-svn-id: https://svn.eduke32.com/eduke32@4415 1a8010ca-5511-0410-912e-c29ae57300e0
Also, extend the documentation for r_usenewshading a little. Specifically,
note when the different modes were introduced. BUILD_LUNATIC.
git-svn-id: https://svn.eduke32.com/eduke32@4410 1a8010ca-5511-0410-912e-c29ae57300e0
It was plainly noticeable in the editor's tile info display, for
example.
git-svn-id: https://svn.eduke32.com/eduke32@4409 1a8010ca-5511-0410-912e-c29ae57300e0
This is done by factoring out some polymer.c:polymer_getbuildmaterial() code
into polymer_eligible_for_artmapping() and using that. The one in polymer.c
can still determine to not use ART mapping on some ("rare"?) occasions, so
it's not 100% in sync.
git-svn-id: https://svn.eduke32.com/eduke32@4407 1a8010ca-5511-0410-912e-c29ae57300e0
