Using rotatesprite with bit 8 clear (scale to viewport) but using
fullscreen clipping bounds is never what we want. Also, tweak for
fake multi.
git-svn-id: https://svn.eduke32.com/eduke32@2932 1a8010ca-5511-0410-912e-c29ae57300e0
This uses the new rotatesprite bit introduced earlier. Also, allow the
HUD-less screen size.
git-svn-id: https://svn.eduke32.com/eduke32@2931 1a8010ca-5511-0410-912e-c29ae57300e0
I checked all direct and transitive uses of that function and am fairly
confident that it is never used.
git-svn-id: https://svn.eduke32.com/eduke32@2930 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
The black translucent background underneath the user map list will now
be drawn with a shade 32 tile 0 instead of tile BLANK, since I've seen
the latter being replaced in some mod. Also, it will look the same
regardless of screen aspect.
git-svn-id: https://svn.eduke32.com/eduke32@2928 1a8010ca-5511-0410-912e-c29ae57300e0
It seems like I broke the blitty/patchy way of drawing it with one of
the last commits.
git-svn-id: https://svn.eduke32.com/eduke32@2926 1a8010ca-5511-0410-912e-c29ae57300e0
This really fixes clearing the borders to the left and right with widescreen
and hud_bgstretch=0. Also, it seems to fix glitches when the "screen size"
is small (ud.screen_size is large).
git-svn-id: https://svn.eduke32.com/eduke32@2924 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
This fixes stuff like the HUD chaingun with widescreen and small "screen sizes"
(in-game viewport). It also makes rotatesprite behave more like classic overall.
I have no idea why it was there in the first place.
git-svn-id: https://svn.eduke32.com/eduke32@2918 1a8010ca-5511-0410-912e-c29ae57300e0
Classic HUD now has correct aspect in widescreen modes, so with the full status
bar, there may be patches of free room left to the left and right.
git-svn-id: https://svn.eduke32.com/eduke32@2914 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
Instead of setting and resetting the [xy]dim globals, use them as locals
in a block (shadowing the globals). Also, do some common subexpression
elimination for clarity.
git-svn-id: https://svn.eduke32.com/eduke32@2908 1a8010ca-5511-0410-912e-c29ae57300e0
When shrunk, the player position is below the floor for some weird reason.
Updatesectorz would set the sector to -1, and the view would not be drawn.
git-svn-id: https://svn.eduke32.com/eduke32@2907 1a8010ca-5511-0410-912e-c29ae57300e0
Also, change type of g_numPlayerSprites (global and mapstate) from inconsistent
uint8_t/char to int8_t.
git-svn-id: https://svn.eduke32.com/eduke32@2897 1a8010ca-5511-0410-912e-c29ae57300e0
This makes sounds like DUKE_GET (item pickup) be heard for the second player
in the splitscreen mod, too.
git-svn-id: https://svn.eduke32.com/eduke32@2890 1a8010ca-5511-0410-912e-c29ae57300e0
This includes mirrors, rooms and masks. Any value other than 0 or 1
that is returned is considered an error (reserved for future use).
git-svn-id: https://svn.eduke32.com/eduke32@2889 1a8010ca-5511-0410-912e-c29ae57300e0
Of course, it still affects the whole screen. Handles pain and lizard spit.
git-svn-id: https://svn.eduke32.com/eduke32@2886 1a8010ca-5511-0410-912e-c29ae57300e0
The sound distance is the minimum of the two. Both point sources as well
as MUSICANDSFX ambient sound is handled.
git-svn-id: https://svn.eduke32.com/eduke32@2885 1a8010ca-5511-0410-912e-c29ae57300e0
The two instances in S_PlaySound3D() and S_Update() were slightly
different as far as sequencing is concerned. However, I think making
it the same has only benefits and may fix some popping sounds when
starting to play a sound and updating it with a different distance
value on the second buffer fill.
git-svn-id: https://svn.eduke32.com/eduke32@2884 1a8010ca-5511-0410-912e-c29ae57300e0
The story: Duke3D 1.5 source had "short frags[MAXPLAYERS][MAXPLAYERS]" and
"clearbufbyte(&frags[0][0],(MAXPLAYERS*MAXPLAYERS)<<1,0L);". In r1625,
g_player[].frags[MAXPLAYERS] was changed from an array of int32_t to one of
uint8_t, but the clearing code
("clearbufbyte(&g_player[i].frags[0],MAXPLAYERS<<1,0L);") stayed. In r2201, I
rewrote clearfrags() under the assumption that it really is supposed to clear
stuff beyond .frags[].
The moral:
1. Write clean code.
2. Use sizeof.
3. Write clean code!
git-svn-id: https://svn.eduke32.com/eduke32@2878 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
Functions affected are G_Move* in actors.c and A_Shoot in player.c.
Here, the p variable had function scope, now it's redeclared in shorter
blocks. I'm still relatively sure that no observable behavior was changed,
though not as sure as in part 1. Also, some dead assignments and the like
are eliminated.
git-svn-id: https://svn.eduke32.com/eduke32@2876 1a8010ca-5511-0410-912e-c29ae57300e0
The p variable (sometimes named differently) has short scope in all cases,
so I'm almost sure that the replacements amount to an identity transformation.
git-svn-id: https://svn.eduke32.com/eduke32@2875 1a8010ca-5511-0410-912e-c29ae57300e0
... against invalid weapon indices and arguments accessed from arrays/structs.
git-svn-id: https://svn.eduke32.com/eduke32@2873 1a8010ca-5511-0410-912e-c29ae57300e0
Also, rewrite the mapastats iterator and the LIZTROOP hitscan timing
in terms of that.
git-svn-id: https://svn.eduke32.com/eduke32@2858 1a8010ca-5511-0410-912e-c29ae57300e0
Also fix error handling path in our_require(), i.e. when loadstring fails.
git-svn-id: https://svn.eduke32.com/eduke32@2857 1a8010ca-5511-0410-912e-c29ae57300e0
The build script now has two more presets: helix and installtools
(which was previously attempted after the build; untested). Also,
- when detecting git, run commands such that the SVN repo isn't accessed
- package kextract, kgroup and arttool into tools/ in the zip
- try to exit on failure in some places, though that doesn't seem to work
git-svn-id: https://svn.eduke32.com/eduke32@2852 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
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
Most notably, -Wdeclaration-after-statement. This and -Wpointer-arith
give some warning on linux, but this is "harmless" as it's assumed that
we'll be always compiling with GCC or Clang there.
Also, erratum in the "Make ksqrt take uint32_t ..." commit:
hypotenuse -> squared length of the hypotenuse
git-svn-id: https://svn.eduke32.com/eduke32@2797 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
Most differences are handled with function parameters, except that one instance
checked SpriteProjectile[i].spawns for being >0 instead of >=0. The factored
function always checks for >=0.
git-svn-id: https://svn.eduke32.com/eduke32@2794 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
The latter shows that "int32_t ksqrt(int32_t)" also copes with values in the
range INT32_MIN..-1, effectively interpreting them as uint32_t (i.e. adding
2**32). However, this should not be relied on from CON.
git-svn-id: https://svn.eduke32.com/eduke32@2790 1a8010ca-5511-0410-912e-c29ae57300e0
The bug was introduced with SAMESIZE_ACTOR_T enabling in r2208.
This fixes being unable to read the messages in A.Dream* by zykov eddy.
git-svn-id: https://svn.eduke32.com/eduke32@2788 1a8010ca-5511-0410-912e-c29ae57300e0
Arrays inside structs must not be accessible, since they're not bound-checked
by the FFI. Therefore, we flatten them into repeated scalar fields and need
to write accessor functions later.
git-svn-id: https://svn.eduke32.com/eduke32@2786 1a8010ca-5511-0410-912e-c29ae57300e0
