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
Instructions on how I built the libs are in Windows/src/minipng.dfa.
git-svn-id: https://svn.eduke32.com/eduke32@2843 1a8010ca-5511-0410-912e-c29ae57300e0
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
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
The event is run after drawing the scene, but before the overlays. To
make a screenshot from a script, set DOSCRSHOT to non-zero. It will then
be scheduled to run once after the drawing but before the above-mentioned
event. The screenshots will be called mcapXXXX.{png,tga}.
git-svn-id: https://svn.eduke32.com/eduke32@2818 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
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
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
The latter is commented out, since it has to be *compiled* with
script_expertmode enabled.
git-svn-id: https://svn.eduke32.com/eduke32@2808 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
-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
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
For SDL 1.2 and when building on linux, the code using
clock_gettime(CLOCK_MONOTINIC, ...) is taken over from SDL HG.
gethitickms() is a convenience function that return milliseconds as
doubles and isn't exposed in any header file, yet.
git-svn-id: https://svn.eduke32.com/eduke32@2778 1a8010ca-5511-0410-912e-c29ae57300e0
Doesn't work: indexed-color modes, gamma (at least for X11), mouse wheel,
special keys like ENTER or BACKSPACE in the OSD, probably more...
In build/Makefile.shared, we now have logic to autodetect an SDL2 installed
in /usr/local, however OS X and Wii builds follow other Makefile code paths,
it seems. Note that the matching SDL2_mixer must be used then, too.
In source/jaudiolib/src/driver_sdl.c, change the #includes from <SDL/SDL_xxx.h>
to "SDL_xxx.h". SDL wiki says this is the most portable way, hopefully this
doesn't break builds for anyone.
git-svn-id: https://svn.eduke32.com/eduke32@2777 1a8010ca-5511-0410-912e-c29ae57300e0
This was actually broken all the time except when ALL sectors were selected
(which was what I tested incidentally when I wrote the first "fix"). D'oh!
git-svn-id: https://svn.eduke32.com/eduke32@2773 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
This is to not slow down the core drawing functions too much in debugging builds
and mimics the way things are on x86.
git-svn-id: https://svn.eduke32.com/eduke32@2755 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
