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
- Use the proper tile sequence when multiple pskies are present in a map.
However, there's still only *one* psky chosen at map load time.
- Handle three horizfrac cases:
* 0, psky always at same level wrt screen
* 65536, psky horiz follows camera horiz (e.g. E4L9)
* otherwise, fall back to default hard-coded parallax implemented as an
angle fraction
git-svn-id: https://svn.eduke32.com/eduke32@3977 1a8010ca-5511-0410-912e-c29ae57300e0
- Rename sky_t members: yscale -> horizfrac, bits -> lognumtiles.
- Add default sky (8 tiles, horizfrac=32768 (i.e. 1/2 the scene horiz), offsets
all zero) and CLOUDYOCEAN sky (8 tiles, horizfrac=65536, offsets all zero)
to multipsky[].
- Get rid of "psky_t g_psky", merely maintaining a g_pskyidx instead. Set it up
at map load time so as to keep the behavior of the legacy per-map psky:
the last sector index with a matching psky ceiling wins.
- In mapstate_t, save g_pskyidx too, not (former) pskybits and pskyoffs[].
- Make on-map-load global psky setup consistent for the game and editor by
factoring it out into common.c: G_SetupGlobalPsky().
- Remove a couple of useless initializations, add some static assertions.
This commit is more likely to introduce subtle differences in behavior.
Specifically, getpsky() now always returns the default sky properties instead of
the global sky ones (but with all-zero offsets) when no match for a suiting
multi-psky is found. This is only likely to affect the yscale/horizfrac of
non-multi-pskies when a global non-default multi-psky has been set up.
Bump BYTEVERSION again.
git-svn-id: https://svn.eduke32.com/eduke32@3976 1a8010ca-5511-0410-912e-c29ae57300e0
- Consolidate psky* arrays into a "typedef struct psky_t" "g_psky" and
"multipsky[]".
- Factor out getting parallaxed sky properties into getpsky().
- Condense initial multi-psky setup by memcpy'ing from multipsky[].
- New function: MultiPsky_TileToIdx().
- Add new define PSKYOFF_MAX and related consistency-checking assertions.
- Lower MAXPSKYTILES to 8 to reflect current usage (was 256).
- Game: make multi-pskies consider dynamically-remapped MOONSKY1, BIGORBIT1
and LA. (Not very useful as the editor will still only act for the static
values -- 80, 84 and 89, respectively.)
An attempt has been made to preserve behavior even in strange cases, so this
commit is unlikely to introduce regressions. Because of point 6, BYTEVERSION
had to be bumped.
git-svn-id: https://svn.eduke32.com/eduke32@3975 1a8010ca-5511-0410-912e-c29ae57300e0
Also, very slightly tweak a factor toward a "brighter" (farther visible)
scene overall to account for the "circular" nature of the fragment distance
(as opposed to an "ortho" distance in Build).
git-svn-id: https://svn.eduke32.com/eduke32@3962 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes the case marked with the silver letter C in test_tileoffsets.map.
The orientation of the sprites is correct (matches classic) as far as I can
see, there are now only problems with translation.
git-svn-id: https://svn.eduke32.com/eduke32@3776 1a8010ca-5511-0410-912e-c29ae57300e0
