erratum in r2844 commit message:
ydim vs. bytesperline --> xdim vs. bytesperline
git-svn-id: https://svn.eduke32.com/eduke32@2849 1a8010ca-5511-0410-912e-c29ae57300e0
This was narrowed to int8_t in r1625, breaking CON code that wanted
to lock the player for a longer time than 127 game tics.
git-svn-id: https://svn.eduke32.com/eduke32@2847 1a8010ca-5511-0410-912e-c29ae57300e0
The tiles used are BIGHOLE (1141) and VIEWBORDER (3250). Ideally we'd draw the
console background using something specially-coded instead of rotatesprite if
it's fully black anyway.
git-svn-id: https://svn.eduke32.com/eduke32@2846 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
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
If input is cleared before, it can become impossible to cancel the video
when decoding and displaying a frame takes longer than a frame.
git-svn-id: https://svn.eduke32.com/eduke32@2833 1a8010ca-5511-0410-912e-c29ae57300e0
The library was built with GCC 4.6.1 and configured like
./configure --disable-vp8-encoder --disable-multithread --disable-spatial-resampling
On the aforementioned AMD system, this reduces the mean time for decoding a frame
from 18.2 to 15.4 ms, so IMO it's worth the somewhat hefty addition of 430 Kb.
git-svn-id: https://svn.eduke32.com/eduke32@2831 1a8010ca-5511-0410-912e-c29ae57300e0
On an AMD Phenom II X4 system with generic memory modules, this brings down
the mean time for this conversion from 16.5 to 10.5 ms.
(GCC 4.6.1, optimized build)
git-svn-id: https://svn.eduke32.com/eduke32@2830 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
The editor colors are the ones listed on page 9 of the Mapster32 built-in help.
git-svn-id: https://svn.eduke32.com/eduke32@2816 1a8010ca-5511-0410-912e-c29ae57300e0
The map iterator now has init/finish capability, making it possible to
write scripts that aggregate data over multiple map files. One such example
calculates some statistics, the other loads art metadata and looks for
red walls with non-pow2 ysize tiles.
git-svn-id: https://svn.eduke32.com/eduke32@2814 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
