This changes a constant inside the panning calculation from 256 to 255 (making
e.g. panning 255 and 0 the same in the "San Andreas fault" sign in E1L5) and
uses the correct reference wall for the "do panning correction?" conditional.
Now, the problematic walls should look the same as in Polymost.
git-svn-id: https://svn.eduke32.com/eduke32@2822 1a8010ca-5511-0410-912e-c29ae57300e0
This makes the corrections conditional on where they appear in (under-, over-,
white or mask wall).
git-svn-id: https://svn.eduke32.com/eduke32@2821 1a8010ca-5511-0410-912e-c29ae57300e0
Non-pow2 wall/mask drawing in classic introduced cases where walls are
drawn "incorrectly" because they were constructed with the old behavior
in mind. Polymer appears to "correct" for it partially, but doesn't cover
all cases. Specifically, now we have:
- E1L1 first inside secret room (5000, 50000): Polymer draws like Duke 1.5,
classic now draws with an offset.
- E3L2 near the vault (-20000, 25000): both classic and Polymer draw with
offsets compared to Duke 1.5, but they're different!
This means that more research is needed into what makes these two cases
diverge, even though both have the same root cause.
!!! Also, mappers should abstain from using non-power-of two textures on
walls until this issue is resolved in a satisfactory fashion !!!
git-svn-id: https://svn.eduke32.com/eduke32@2811 1a8010ca-5511-0410-912e-c29ae57300e0
-Wwrite-strings is useful to detect code where string literals and e.g. alloc'd
strings are used side-by-side, potentially creating dangerous situations, or to
find uses of old, non-constified APIs. However, enabling it would still flood
the log with too many warnings. Also, GCC wrongly warns for initializations of
char arrays.
git-svn-id: https://svn.eduke32.com/eduke32@2796 1a8010ca-5511-0410-912e-c29ae57300e0
Specifically, it was in the "determine searchwall when aiming at floor or
ceiling" part. Now, if prsectors[]->ceil.plane (or ->floor.plane) is NULL,
we set the searchwall to the sector's firstwall and return.
git-svn-id: https://svn.eduke32.com/eduke32@2610 1a8010ca-5511-0410-912e-c29ae57300e0
This was broken ever since updatesprite() had been forked off drawsprite() and
would cause static lights to never hit static sprites until one or the other
changed, after which the light would always get culled against outdated sprite
geometry.
git-svn-id: https://svn.eduke32.com/eduke32@2536 1a8010ca-5511-0410-912e-c29ae57300e0
Since updatesprite() only happens once for static sprites, avoiding
light culling if we hit it in a shadow pass means that sprite will
never be lit as long as that happens.
git-svn-id: https://svn.eduke32.com/eduke32@2535 1a8010ca-5511-0410-912e-c29ae57300e0
With VBOs enabled, the virtual pointer to the geometry of frame 0 of a model
is always NULL. This was confusing the polymer code responsible for deciding
whether to enable smooth animations or not, which meant that any animation
that would loop to frame 0 would do it as if animation interpolation was
disabled, which looks very choppy.
git-svn-id: https://svn.eduke32.com/eduke32@2443 1a8010ca-5511-0410-912e-c29ae57300e0
The following functions have const qualifiers attached for the 'destination'
arguments: kdfwrite, dfwrite in cache1d.c and copybuf{byte,reverse,} in the
pragmas source or headers. A couple uses of the latter ones were replaced
with calls to standard library functions.
git-svn-id: https://svn.eduke32.com/eduke32@2361 1a8010ca-5511-0410-912e-c29ae57300e0
Internally, updateanimation() now takes a third parameter 'lpal'.
git-svn-id: https://svn.eduke32.com/eduke32@2277 1a8010ca-5511-0410-912e-c29ae57300e0
The cause was a combination of many factors. First, Polymer requires the
start-drawing position to be inside the sector to draw (deviations lead to
incorrect drawing). This was violated by the game, because it interpolated
the current and next tic position without updating the sectnum, leading to
inconsistencies especially when passing through narrow sectors. Polymer
worked around it by doing an updatesector() each frame, however this works
poorly for maps with overlapping geometry such as SoS or RoR.
The solution to this is to add a new engine function,
updatesector_onlynextwalls(), which searches the sectors (via nextsector)
in breadth-first fashion instead of from 0 to numsectors-1, like updatesector
does when it fails for the *immediate* nextwall neighbors.
Internally, the breadt-first search helpers are moved into the engine.
git-svn-id: https://svn.eduke32.com/eduke32@2256 1a8010ca-5511-0410-912e-c29ae57300e0
Also, for debugging builds, show this message from verbosity level 1 on.
git-svn-id: https://svn.eduke32.com/eduke32@2250 1a8010ca-5511-0410-912e-c29ae57300e0
the SE ones douple, triple, ... after each save. Maphack lights are reloaded
with polymer_resetlights() (though I've had them disappearing after load, I
couldn't reproduce it afterwards).
- in debugging builds, print a message when polymer_resetlight is called on a
nonexistent one. The problem is not so much the call itself (it's guarded),
but the fact that resources on the caller side may not have been freed if it
thinks that those lights do in fact exist. Right now, it's not the case though.
- add 'loaded map hack' messages after some other successful loadmaphack calls
git-svn-id: https://svn.eduke32.com/eduke32@2236 1a8010ca-5511-0410-912e-c29ae57300e0
fashion. Among other things, this makes the FOV widening when shrunk
work. User CON code should always check the initial viewingrange value
when attempting to do FOV effects like zoom, because it is not guaranteed
to be 65536 due to different screen aspect ratios etc.
git-svn-id: https://svn.eduke32.com/eduke32@2078 1a8010ca-5511-0410-912e-c29ae57300e0
polymer_addlight(). I have no idea whether it's the 'right' thing,
but it fixes this:
Conditional jump or move depends on uninitialised value(s)
at polymer_updatelights (polymer.c:5090)
by polymer_drawrooms (polymer.c:938)
. . .
Uninitialised value was created by a stack allocation
at loadmaphack (engine.c:9482)
Fix another uninitialized access when rendering jpegs.
git-svn-id: https://svn.eduke32.com/eduke32@2069 1a8010ca-5511-0410-912e-c29ae57300e0
Getting the texture handles without requiring invalidation means we can
handle ART-animating tilenums without impacting performance too much.
git-svn-id: https://svn.eduke32.com/eduke32@2058 1a8010ca-5511-0410-912e-c29ae57300e0
This won't actually do anything until the a debug bit is added when
creating the context, but that requires support for GLX_create_context
which SDL doesn't support. I'll add support for WGL_create_context to
winlayer in a bit as a stopgap.
Also updates our local copy of glext.h with a fresh one from the
Khronos registry.
git-svn-id: https://svn.eduke32.com/eduke32@2056 1a8010ca-5511-0410-912e-c29ae57300e0
We need to Y-invert the projection texcoords when sampling
from the lightmap.
git-svn-id: https://svn.eduke32.com/eduke32@2055 1a8010ca-5511-0410-912e-c29ae57300e0
Sprites would stick with their old material on global palette change.
This goes through all prsprites and clobbers their CRCs so that an
alternate skin / tint / highpal can be applied accordingly.
git-svn-id: https://svn.eduke32.com/eduke32@2053 1a8010ca-5511-0410-912e-c29ae57300e0
The winding order of faces is different if only flipping about X or Y,
and we were unconditionally culling CW faces.
git-svn-id: https://svn.eduke32.com/eduke32@2052 1a8010ca-5511-0410-912e-c29ae57300e0
First, if we're in Polymer, don't precache tinted tiles that have a highpal
for that certain pal. Second, don't precache tiles for palnum 251 (the last
non-reserved one, which is used as a crosshair pal). Assuming that there are
no other tints, this cuts the initial precache time and cache size on disk in
half.
git-svn-id: https://svn.eduke32.com/eduke32@2045 1a8010ca-5511-0410-912e-c29ae57300e0
Keep track of which side is getting culled, swap around mirrors, swap
around model drawing.
git-svn-id: https://svn.eduke32.com/eduke32@2032 1a8010ca-5511-0410-912e-c29ae57300e0
is present (like in E4L1). Also sneak in a trivial change in cache1d.c
git-svn-id: https://svn.eduke32.com/eduke32@2010 1a8010ca-5511-0410-912e-c29ae57300e0
In cases where performing occlusion queries for multiple red walls
leading to the same sector, we would sometimes leak a number of
query objects. This was apparently harmless on NVIDIA drivers, but
would leak tons of memory on ATI.
git-svn-id: https://svn.eduke32.com/eduke32@1993 1a8010ca-5511-0410-912e-c29ae57300e0
The code was using the Polymer-cached version of the sector cstat to
determine the translucency of its diffuse material, meaning it would
never get it right on the first try; that's what you get for having
completely different variables named 's' and 'sec'.
git-svn-id: https://svn.eduke32.com/eduke32@1991 1a8010ca-5511-0410-912e-c29ae57300e0
We normally enable backface culling always, but turn it off for
two-sided sprites; we need to make sure it's re-enabled after that
as sector masks are drawn after.
git-svn-id: https://svn.eduke32.com/eduke32@1990 1a8010ca-5511-0410-912e-c29ae57300e0
Some of the ROR code was operating under the assumption that drawasks
always correspond to one call of polymer_displarooms(), but that's not
necessarily the case; external view draws all sectors from the top
polymer_drawrooms(), which was causing crashes. Just ignore the sector
mask queues in external view mode, we already don't draw masked walls.
git-svn-id: https://svn.eduke32.com/eduke32@1982 1a8010ca-5511-0410-912e-c29ae57300e0
Check all the bunch siblings if we get a floor/ceiling hit and walk
them if their own planes hit.
git-svn-id: https://svn.eduke32.com/eduke32@1981 1a8010ca-5511-0410-912e-c29ae57300e0
When walking the sectors in displayrooms, detect floor/sector masks to
place them in a mask queue. The queues are allocated on the heap, but
a stack pointer is maintained by the displayrooms to allow it to play
nice with mirror recursion.
Right now the masks are drawn after all of drawmasks is finished; that
means you can see sprites and wall masks through sector masks, but not
the opposite. There is a slight attempt at blending far to near, but
nothing too conclusive yet; that means that in some cases some sector
masks won't be visible through other sector masks, but it should work
for trivial cases.
The next step would be to copy all the drawmasks logic into Polymer
and have it (attempt to) properly interleave sector masks where they
belong in the blending order.
git-svn-id: https://svn.eduke32.com/eduke32@1980 1a8010ca-5511-0410-912e-c29ae57300e0
Previously they would get counted both as 1-way walls for immediate
drawing and as mask walls for delayed drawing.
git-svn-id: https://svn.eduke32.com/eduke32@1979 1a8010ca-5511-0410-912e-c29ae57300e0
Assigns the right alpha value to floor/ceiling planes if their
translucency bits are set and make sure that changing the cstat now
triggers an update of the material for editing purposes.
This doesn't do anything by itself, but will be needed to correctly
draw floor/ceiling masks.
git-svn-id: https://svn.eduke32.com/eduke32@1977 1a8010ca-5511-0410-912e-c29ae57300e0
When walking the sectors, put more drawing work between queuing and
reaping the occlusion queries to potentially make them more efficient.
git-svn-id: https://svn.eduke32.com/eduke32@1976 1a8010ca-5511-0410-912e-c29ae57300e0
Enumerate the vertical siblings of each walked sector and check them
against the current frustum. No occlusion queries yet, but that should
correct any missing sectors until a flaw in that logic is discovered.
git-svn-id: https://svn.eduke32.com/eduke32@1975 1a8010ca-5511-0410-912e-c29ae57300e0
Reorganize polymer.c a bit to match the order of prototypes from the
header, move macros from the middle into the header.
git-svn-id: https://svn.eduke32.com/eduke32@1974 1a8010ca-5511-0410-912e-c29ae57300e0
