-Sort by owner now occurs only when two sprites have matching x/y coordinates.
-Cstat 1024 now activates a special drawing mode that indicates a sprite should be drawn without depth after all other sprites have been drawn. The previous cstat 1024 functionality, an internal hack for shadows cast by models in Polymost, has been moved to bit 1 of a new graphical effects bitfield stored in a tsprite's .extra member.
git-svn-id: https://svn.eduke32.com/eduke32@5400 1a8010ca-5511-0410-912e-c29ae57300e0
It does not depend on the "swap bottom wall parts" bit being set.
The fix is by matching up the related code with Polymost.
git-svn-id: https://svn.eduke32.com/eduke32@5230 1a8010ca-5511-0410-912e-c29ae57300e0
I have commented out the versions of these functions that perform bitmasks and shifts and replaced them with versions that cast to and from integral types, pending performance and compatibility research across platforms.
git-svn-id: https://svn.eduke32.com/eduke32@5174 1a8010ca-5511-0410-912e-c29ae57300e0
0 - Multiply
64 - Screen
128 - Overlay
192 - Hard Light
Note: These will likely look terrible when combined with the Colorize flag, because of the nature of the Colorize flag.
git-svn-id: https://svn.eduke32.com/eduke32@5146 1a8010ca-5511-0410-912e-c29ae57300e0
This prevents displaying W_FORCEFIELD+1 masks (as e.g. in front of viewscreens)
completely black with ART mapping. The old behavior, which is inconsistent with
classic, is kept for one-sided masked walls, though.
git-svn-id: https://svn.eduke32.com/eduke32@4830 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
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
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
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
With this mode, the near distance of the linear fog is always 0, unlike being
negative with r_usenewshading 2.
git-svn-id: https://svn.eduke32.com/eduke32@4393 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes updating the viewscreen in Polymer's ART mapping mode.
git-svn-id: https://svn.eduke32.com/eduke32@4304 1a8010ca-5511-0410-912e-c29ae57300e0
Redundant for the same reason as the preceding one: the pointer has already
been dereferenced at the point the check is made. Also, all 5 calls of that
function pass a valid pointer (provided the pointers from which the expressions
are derived are valid). Reported by Stack, too.
git-svn-id: https://svn.eduke32.com/eduke32@4017 1a8010ca-5511-0410-912e-c29ae57300e0
