Unconditionally enabled, but useful for comparing the behavior of the 1-column
vline functions against the 2- or 4-column ones.
git-svn-id: https://svn.eduke32.com/eduke32@3311 1a8010ca-5511-0410-912e-c29ae57300e0
The former is really only a workaround. Walls/vertical sprites/pskies with
ysize 512 (and presumably greater, but this was not tested) are rendered
with one shade higher at the borders (1 pixel vlines) because of a certain
assumption in the ASM (see comments there). With very dark shades, the
palookup[] buffer is accessed oob. We simply allocate 256 bytes more at the
end for each.
The latter is only for CLASSIC_NONPOW2_YSIZE_WALLS builds, which is not enabled
yet. It seems to matter only for the uncommon case where the such pskies repeat
in the height. A 1680x1050 window fully covered with such a sky is then rendered
at about 60/85 the FPS for me (mostly due to not using the 4 pixel vline
routines), so it may be leaning a bit too much on the side of correctness.
A compilation switch DEBUG_TILESIZY_512 is introduced in engine.c for
demonstration purposes.
git-svn-id: https://svn.eduke32.com/eduke32@3310 1a8010ca-5511-0410-912e-c29ae57300e0
- If aiming at a swapped bottom wall, display "Wall <wallnum> -> <otherwallnum>"
- highlight pic, shade, pal, cstat in yellow then
- in printext256, accept at most 3 digits for the color format string (e.g. ^123)
git-svn-id: https://svn.eduke32.com/eduke32@3308 1a8010ca-5511-0410-912e-c29ae57300e0
This global option will set bit 1024 and clear bits 256 and 512 for all
rotatesprite calls, fixing complex HUD drawing code relying on precise
alignment of individual elements (widescreen rotatesprite is entirely
unsuitable for this purpose).
git-svn-id: https://svn.eduke32.com/eduke32@3284 1a8010ca-5511-0410-912e-c29ae57300e0
The two uses are from hitscan and neartag. The functionality is reproduced
exactly (assuming I made no mistake), down to different distance checking
(<= vs. <).
git-svn-id: https://svn.eduke32.com/eduke32@3228 1a8010ca-5511-0410-912e-c29ae57300e0
This function also changed: it doesn't handle floor-aligned sprites now,
and the z offset is returned instead of set by pointer.
git-svn-id: https://svn.eduke32.com/eduke32@3205 1a8010ca-5511-0410-912e-c29ae57300e0
The size of that struct is currently 4, and its layout almost the same as
what is read in with loadpics(). The number of tiles in an animation is
bumped to 256, so that the max. tile difference in DEF's animtilerange is
255. (There's no way to have such animations from ART.)
git-svn-id: https://svn.eduke32.com/eduke32@3202 1a8010ca-5511-0410-912e-c29ae57300e0
Notes:
- Atomic Edition (Censored) -> Plutonium Pak in grpscan.c
- "scale" in astub.c:drawtileinfo() is incorrect, I think.
- in demo.c, the gethitickms() value should be returned to a double.
git-svn-id: https://svn.eduke32.com/eduke32@3178 1a8010ca-5511-0410-912e-c29ae57300e0
NOTE: changes such as these are best viewed with something like
git diff (...) --color-words='[a-zA-Z0-9_]+|[^[:space:]]'
git-svn-id: https://svn.eduke32.com/eduke32@3176 1a8010ca-5511-0410-912e-c29ae57300e0
Note the type change of vplce[] in engine.c: int32_t -> uint32_t.
git-svn-id: https://svn.eduke32.com/eduke32@3172 1a8010ca-5511-0410-912e-c29ae57300e0
This reverts r3159..r3161.
Conflicts:
eduke32/build/include/compat.h
(Handled so that r3163's changes are kept applied.)
git-svn-id: https://svn.eduke32.com/eduke32@3165 1a8010ca-5511-0410-912e-c29ae57300e0
I think there's also a fix for the CON precache system breakage in here (lost it in my local tree when I started getting the C++ build working in MSVC, sorry!)
git-svn-id: https://svn.eduke32.com/eduke32@3159 1a8010ca-5511-0410-912e-c29ae57300e0
Also, enable showing sprites in Mapster32's overhead view again, since that
was one (the only?) use of that code path. The uninitialized read was
introduced in r2927.
git-svn-id: https://svn.eduke32.com/eduke32@3144 1a8010ca-5511-0410-912e-c29ae57300e0
Credit to Plagman for the idea and doing the work on the game side, which is included in this commit.
(Building as C++ will give us features with which we can make improvements and optimizations on the multiplayer code and Polymer.)
git-svn-id: https://svn.eduke32.com/eduke32@3116 1a8010ca-5511-0410-912e-c29ae57300e0
The attribute is set per tile from DEF: either
texhitscanrange <begintile> <endtile>
or
tilefromtexture <tile> { ... texhitscan ... }
(As a special case, the list may only contain "texhitscan", in which case the
texture is not changed.)
In passing, do some cleanup for "tilefromtexture" DEF parsing: the list tokens
should now be accepted in any order, and errors don't appear in the middle of
the list parsing.
git-svn-id: https://svn.eduke32.com/eduke32@3078 1a8010ca-5511-0410-912e-c29ae57300e0
This means that loadoldboard() now should also initialize Polymer map
info after loading a v5/v6 map. Make the variables holding a file descriptor
an int32_t instead of int16_t.
git-svn-id: https://svn.eduke32.com/eduke32@3044 1a8010ca-5511-0410-912e-c29ae57300e0
- make inside_editor() static in build.c
- replace comparisons of inside()'s return values with 0 by ones with 1
(since a returned 0 can mean -1 or 1, i.e. oob sector or is really inside)
- prevent a theoretically possible oob access in correct_ornamented_sprite()
git-svn-id: https://svn.eduke32.com/eduke32@3038 1a8010ca-5511-0410-912e-c29ae57300e0
- factor out the "is inside" predicates
- rename updatesector_onlynextwalls() -> updatesectorbreadth()
- add ATTRIBUTE((nonnull(4))) to the bitmap arg of updatesectorexclude().
git-svn-id: https://svn.eduke32.com/eduke32@3037 1a8010ca-5511-0410-912e-c29ae57300e0
Previously, we used them in our builds for sprites, but MSVC builds don't have
the ASM ported to MASM, and thus the workaround of ignoring the linking errors
was not safe.
git-svn-id: https://svn.eduke32.com/eduke32@3031 1a8010ca-5511-0410-912e-c29ae57300e0
Hendricks found a bug caused by that commit, so this one enables exprimentation
with setbrightness() bit 1 behavior.
git-svn-id: https://svn.eduke32.com/eduke32@3025 1a8010ca-5511-0410-912e-c29ae57300e0
This makes the splitscreen mod not have a ridiculous view distortion.
Such scenes will have no correction for non-square pixels, though.
git-svn-id: https://svn.eduke32.com/eduke32@3020 1a8010ca-5511-0410-912e-c29ae57300e0
This trims four 4k pages of code from the release EDuke32 build and
one page from Mapster32.
git-svn-id: https://svn.eduke32.com/eduke32@2991 1a8010ca-5511-0410-912e-c29ae57300e0
When this happens, parallaxmodes other than 0 will be unavailable and silently
draw as parallaxmode 0. This usually happens with extremely wide resolutions.
git-svn-id: https://svn.eduke32.com/eduke32@2990 1a8010ca-5511-0410-912e-c29ae57300e0
We're pulling stuff from math.h even in non-GL builds right now, so
adding libc's sin() and atan() doesn't seem like a big deal. In the
unlikely event that their accuracy is so bad that the calculated tables
don't match the original ones, a warning is issued on little-endian
platforms.
git-svn-id: https://svn.eduke32.com/eduke32@2988 1a8010ca-5511-0410-912e-c29ae57300e0
A debug macro to test tints being stuck at the least intense non-zero value
is provided in engine.c.
git-svn-id: https://svn.eduke32.com/eduke32@2952 1a8010ca-5511-0410-912e-c29ae57300e0
ROTATESPRITE_MAX is moved to build.h and all orientation bits from CON commands
using rotatesprite are ANDed with (ROTATESPRITE_MAX-1). Some of the functions
use ROTATESPRITE_MAX for different internal purposes, which will not be exposed
to CON now (a good thing). Also, dorotspr_handle_bit2 is made clearer.
git-svn-id: https://svn.eduke32.com/eduke32@2929 1a8010ca-5511-0410-912e-c29ae57300e0
Don't call setaspect from them, because the only thing that's needed is
(in classic) yxaspect and xyaspect. Pass these from the helper function
defined earlier instead.
git-svn-id: https://svn.eduke32.com/eduke32@2921 1a8010ca-5511-0410-912e-c29ae57300e0
setaspect(), which is called by setaspect_new, already uses the *dimen variables,
so it's the same thing done twice. Now, a change from the original full status
bar to the original mini status bar keeps the horizontal FOV again and only
bumps the view a little higher, as with the classic aspect determination.
git-svn-id: https://svn.eduke32.com/eduke32@2913 1a8010ca-5511-0410-912e-c29ae57300e0
This means that classic and the GL modes now look the same as far as e.g.
hud_bgstretch or HUD weapons are concerned.
git-svn-id: https://svn.eduke32.com/eduke32@2911 1a8010ca-5511-0410-912e-c29ae57300e0
This makes the code rather more readable in some places. Unlike the two
preceding commits, this one is actually purely textual replacement.
git-svn-id: https://svn.eduke32.com/eduke32@2877 1a8010ca-5511-0410-912e-c29ae57300e0
The idiv instruction also signals an FPE when the resulting *signed* quotient
overflows, so we simply use div instead.
git-svn-id: https://svn.eduke32.com/eduke32@2850 1a8010ca-5511-0410-912e-c29ae57300e0
These could manifest themselves as garbage lines on the bottom and
happened because of the ydim vs. bytesperline discrepancy again.
git-svn-id: https://svn.eduke32.com/eduke32@2844 1a8010ca-5511-0410-912e-c29ae57300e0
I'm willing to make this one concession to correctness in the name of backward-
compatibility. I think that one reason why this has never cause a crash is that
tiles in BUILD are allocated in Ken's big allocache buffer, so oob accesses were
dampened by that (though they hit uninitialized data).
git-svn-id: https://svn.eduke32.com/eduke32@2819 1a8010ca-5511-0410-912e-c29ae57300e0
This would only hit when polymost_printext256 erred out (mem alloc failure,
glGenTextures failure), i.e. "almost never".
Also, tweak a bound check in polymost_printext256.
git-svn-id: https://svn.eduke32.com/eduke32@2817 1a8010ca-5511-0410-912e-c29ae57300e0
This was introduced with r2771, which fixed e.g. AMC TC city_si's mirrors,
but instructed the base drawrooms inside yax_drawrooms to not correct the
passed sectnum. Therefore, stuff would get drawn wrongly when passing
sector boundaries, like from the platform to the rails in trueror1.map.
git-svn-id: https://svn.eduke32.com/eduke32@2810 1a8010ca-5511-0410-912e-c29ae57300e0
Related to that, it looks like out-of-bounds accesses when drawing such walls/
maskwalls or *sprites* are fixed, too. Sprites still show a stray lines on some
occasions, but Valgrind doesn't complain then.
git-svn-id: https://svn.eduke32.com/eduke32@2805 1a8010ca-5511-0410-912e-c29ae57300e0
uhypsq calculates the hypotenuse using unsigned multiplication. This is
permissible since for arbitrary int32s a and b, the following holds in
two's complement arithmetic:
(int32_t)((uint32_t)a * b) == (int32_t)((int64_t)a * b)
("Signed and unsigned multiplication is the same on the bit level.")
This fixes various overflows where wall lengths for walls of length > 46340
are calculated, but does not rid us of other overflows in the same vein
(usually dot products between vectors where one point is a wall vertex and
the other a position in a sector).
git-svn-id: https://svn.eduke32.com/eduke32@2791 1a8010ca-5511-0410-912e-c29ae57300e0
That is, "clang -ftrapv" builds don't abort almost immediately after entering
a level.
There are various classes of overflow bugs, needing different handling:
- Some texture mapping code was written with signed integer wrapping semantics
in mind. In some places, we're able to get away with unsigned casts.
- sometimes, we really need a wider range, like when calculating distances or
dot products
- negating INT_MIN. Here, we cast to int64_t temporarily. Note that if the
result is 32-bit wide, no 64-bit code may actually need to be generated.
- shifting into a signed integer's sign bit. We cast to uint32 here.
- in hitscan(), at the "abyss crash prevention code" comment, it's clearly
the other code that is better...
This is not merely done for pedantry, but rather makes it easier to track down
overflow bugs having a real impact on the game.
git-svn-id: https://svn.eduke32.com/eduke32@2784 1a8010ca-5511-0410-912e-c29ae57300e0
It's time to replace some int32s with 64-bit ints in core engine functions.
The problem is that for example, the dot product is taken between vectors that
may be the difference between two arbitrary points in a sector, so even if one
sticks to the "no blue walls" rule, that doesn't guarantee freedom from
overflows.
git-svn-id: https://svn.eduke32.com/eduke32@2761 1a8010ca-5511-0410-912e-c29ae57300e0
Bang! One more invalid internals exposure squashed. Maybe one day we'll be able
to call EDuke32 "stable"...
Actually the offending sprite IS drawn as face sprite with shade 32 and xrepeat
and yrepeat 255 for the convenience of the CON coder who will have to debug it.
git-svn-id: https://svn.eduke32.com/eduke32@2744 1a8010ca-5511-0410-912e-c29ae57300e0
Those were happening when wall drawing in an upper/lower layer "closed" too
much of the "curtain" (umost/dmost) for subsequent drawing in that portal.
Example: looking down the sewer manhole at the beginning of Retaliation will
now render without HOM.
git-svn-id: https://svn.eduke32.com/eduke32@2739 1a8010ca-5511-0410-912e-c29ae57300e0
