- For setting 1, don't draw them for red walls whose sector floors have equal
height.
- Make setting 1 the default, because I consider drawing them for such walls
(and white walls) noise (as opposed to information). The "verbose" setting 2
is still available.
git-svn-id: https://svn.eduke32.com/eduke32@4007 1a8010ca-5511-0410-912e-c29ae57300e0
- Use the proper tile sequence when multiple pskies are present in a map.
However, there's still only *one* psky chosen at map load time.
- Handle three horizfrac cases:
* 0, psky always at same level wrt screen
* 65536, psky horiz follows camera horiz (e.g. E4L9)
* otherwise, fall back to default hard-coded parallax implemented as an
angle fraction
git-svn-id: https://svn.eduke32.com/eduke32@3977 1a8010ca-5511-0410-912e-c29ae57300e0
- Rename sky_t members: yscale -> horizfrac, bits -> lognumtiles.
- Add default sky (8 tiles, horizfrac=32768 (i.e. 1/2 the scene horiz), offsets
all zero) and CLOUDYOCEAN sky (8 tiles, horizfrac=65536, offsets all zero)
to multipsky[].
- Get rid of "psky_t g_psky", merely maintaining a g_pskyidx instead. Set it up
at map load time so as to keep the behavior of the legacy per-map psky:
the last sector index with a matching psky ceiling wins.
- In mapstate_t, save g_pskyidx too, not (former) pskybits and pskyoffs[].
- Make on-map-load global psky setup consistent for the game and editor by
factoring it out into common.c: G_SetupGlobalPsky().
- Remove a couple of useless initializations, add some static assertions.
This commit is more likely to introduce subtle differences in behavior.
Specifically, getpsky() now always returns the default sky properties instead of
the global sky ones (but with all-zero offsets) when no match for a suiting
multi-psky is found. This is only likely to affect the yscale/horizfrac of
non-multi-pskies when a global non-default multi-psky has been set up.
Bump BYTEVERSION again.
git-svn-id: https://svn.eduke32.com/eduke32@3976 1a8010ca-5511-0410-912e-c29ae57300e0
- Consolidate psky* arrays into a "typedef struct psky_t" "g_psky" and
"multipsky[]".
- Factor out getting parallaxed sky properties into getpsky().
- Condense initial multi-psky setup by memcpy'ing from multipsky[].
- New function: MultiPsky_TileToIdx().
- Add new define PSKYOFF_MAX and related consistency-checking assertions.
- Lower MAXPSKYTILES to 8 to reflect current usage (was 256).
- Game: make multi-pskies consider dynamically-remapped MOONSKY1, BIGORBIT1
and LA. (Not very useful as the editor will still only act for the static
values -- 80, 84 and 89, respectively.)
An attempt has been made to preserve behavior even in strange cases, so this
commit is unlikely to introduce regressions. Because of point 6, BYTEVERSION
had to be bumped.
git-svn-id: https://svn.eduke32.com/eduke32@3975 1a8010ca-5511-0410-912e-c29ae57300e0
Having to tag these few variables and functions as ATTRIBUTE((used))
seems sensible, but what follows is just strange. OSD_Printf? headspritesect?
git-svn-id: https://svn.eduke32.com/eduke32@3932 1a8010ca-5511-0410-912e-c29ae57300e0
Also, get rid of the strange filename[len]=255 hack in loadboard()
and make its file name arg const char* at last.
git-svn-id: https://svn.eduke32.com/eduke32@3913 1a8010ca-5511-0410-912e-c29ae57300e0
Also, clean up the saving/loading logic a bit:
- On load failure, display message with purple color.
- Take over the current file name ('boardfilename') only on success.
- Check SaveBoard() return values in various places.
git-svn-id: https://svn.eduke32.com/eduke32@3911 1a8010ca-5511-0410-912e-c29ae57300e0
In other words, for a test rectangular sector, a sprite would be inside the
sector in on all 4 edges and all 4 corners. Previously, it would have been
the lower right portion only (*excluding* LL and UR corners), which led to
map editing issues.
git-svn-id: https://svn.eduke32.com/eduke32@3898 1a8010ca-5511-0410-912e-c29ae57300e0
The main thing to note is the "half-open" nature of the x/y range checks.
git-svn-id: https://svn.eduke32.com/eduke32@3897 1a8010ca-5511-0410-912e-c29ae57300e0
Interestingly, that test case then appears to be drawn fully. Heh.
Also, move one clamp from r1874 one up in the data flow chain.
Doesn't seem to break textured overhead map view with Last Pissed Time.
git-svn-id: https://svn.eduke32.com/eduke32@3878 1a8010ca-5511-0410-912e-c29ae57300e0
Also add an assertion that currently sometimes fails when zooming in too much
in Mapster32 textured 2D mode. Example: DNF's LADYKILLR.MAP at (46000,-14000).
git-svn-id: https://svn.eduke32.com/eduke32@3877 1a8010ca-5511-0410-912e-c29ae57300e0
Analogously for the negation; remove a couple of redundant decls of "qsetmode".
git-svn-id: https://svn.eduke32.com/eduke32@3823 1a8010ca-5511-0410-912e-c29ae57300e0
The 'x' is for "extended", since its last arg is a switch of whether to disable
sliding. Use that from gameexec.c.
git-svn-id: https://svn.eduke32.com/eduke32@3811 1a8010ca-5511-0410-912e-c29ae57300e0
Also, update test_tileoffsets.map with a new 'dimension': cstat 128
(sprite centering). It has an issue in Polymer marked with a silver D.
git-svn-id: https://svn.eduke32.com/eduke32@3777 1a8010ca-5511-0410-912e-c29ae57300e0
Among other things, rotatesprite doesn't cope well with large zoom values.
Two assertions are added that guard qinterpolatedown16short() calls: in
the failing case, they would write outside the destination arrays.
Another (existing) assertion is commented a little and like for the first,
instructions are given how to reproduce its failure.
git-svn-id: https://svn.eduke32.com/eduke32@3754 1a8010ca-5511-0410-912e-c29ae57300e0
... in the auto-correction. Also,
- make two similar corruptions level 5 (wallptr oob, wallptr+wallnum oob).
- in drawscreen_drawwall(), do a more strict bound check, not only >=0.
git-svn-id: https://svn.eduke32.com/eduke32@3745 1a8010ca-5511-0410-912e-c29ae57300e0
In the mirror reversing code, get rid of the padding. This may produce
seams, but they appear to be extremely transient and shouldn't be
noticeable.
In game.c, add a debugging compilation switch DEBUG_MIRRORS_ONLY.
git-svn-id: https://svn.eduke32.com/eduke32@3726 1a8010ca-5511-0410-912e-c29ae57300e0
No functional changes, but a (commented out) debug line for an oob read of the
frame buffer when the mirror covers the whole screen is inserted.
git-svn-id: https://svn.eduke32.com/eduke32@3719 1a8010ca-5511-0410-912e-c29ae57300e0
- Return early from drawsprite_classic() if tspr->owner if oob.
Commonize that check between renderers into bad_tspr().
- Make the BIT() macro a left-shift of the *unsigned* number 1,
preventing expansion to (1<<31).
git-svn-id: https://svn.eduke32.com/eduke32@3717 1a8010ca-5511-0410-912e-c29ae57300e0
LameDuke's shade table has 32 gradients of shade, like Duke3D.
For the translucency table though, only the diagonal + one half is stored
because it's symmetric (50/50 translucency).
git-svn-id: https://svn.eduke32.com/eduke32@3709 1a8010ca-5511-0410-912e-c29ae57300e0
- colorize the trailing part if there is corruption or (new) if sprites were
removed
- also corrupt-check when loading <V7 map
- move start{pos,ang,sectnum} to build.c
- remove pointless ...[].extra = -1 before loading map, scantoasc*[] comment
git-svn-id: https://svn.eduke32.com/eduke32@3697 1a8010ca-5511-0410-912e-c29ae57300e0
Sprites are now considered to have out of bounds sector numbers if it is
< 0 or >= numsectors (not merely >= MAXSECTORS). If such a sprite is now
encountered during post-load, an attempt is made first to assign it a sector
number (using updatesector()). If that fails, the sprite is removed from the
map. The background is that a dozen of maps do come with such sprites and
could previously corrupt the sprite list when loaded.
git-svn-id: https://svn.eduke32.com/eduke32@3696 1a8010ca-5511-0410-912e-c29ae57300e0
- Rewrite some sprites-of-{stat,sector} loops using the SPRITES_OF,
SPRITES_OF_SECT and new SPRITES_OF_SECT_SAFE macros.
- In passing, identify some problems and mark them with 'XXX', but don't
attempt to fix them yet.
- The usual readability improvements...
git-svn-id: https://svn.eduke32.com/eduke32@3679 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes liztroops not passing TROR layers when on the jetpack, as well as
other enemies capable of moving upward, and also COMMANDER and DRONE (for which
the code is special-cased).
git-svn-id: https://svn.eduke32.com/eduke32@3666 1a8010ca-5511-0410-912e-c29ae57300e0
... like was done with clipmove() previously.
Also, do some code clean up. There are no changes of functionality.
git-svn-id: https://svn.eduke32.com/eduke32@3662 1a8010ca-5511-0410-912e-c29ae57300e0
The Lunatic build compiles with new structures for sector and wall types.
They have separate members for TROR {up,down}{bunch,nextwall}, so there are
no conflicts with other uses of members into which they were previously
shoehorned. Also, the maximum bunch limit is bumped to 512 in that build.
Currently, loading from V7/8/9 and saving to V7 and V8 are supported.
git-svn-id: https://svn.eduke32.com/eduke32@3658 1a8010ca-5511-0410-912e-c29ae57300e0
Previously, only the <0 condition was checked. However, the passed sectnums
could be >= MAXSECTORS (at least in C-CON), for example when issuing 'canseespr'
on a sprite not in the game world.
git-svn-id: https://svn.eduke32.com/eduke32@3603 1a8010ca-5511-0410-912e-c29ae57300e0
This enables ART animations to take effect on voxels in classic, voxels and models in Polymost, and models in Polymer.
git-svn-id: https://svn.eduke32.com/eduke32@3580 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes an update issue: start EDuke32 without warping to a map in Polymost,
change to classic, and change to Polymost again. The OSD background will be
displaced.
git-svn-id: https://svn.eduke32.com/eduke32@3525 1a8010ca-5511-0410-912e-c29ae57300e0
Face- and wall-aligned sprites are drawn using the wall routines in BUILD.
However, the per-x-screen-coordinate distance (swall[]) is calculated in a way
that potentially incurs great precision loss (for example 5 bits for
xdimen=1280, yxaspect=65536). This leads to the starting (top) vertical texture
coordinate possibly wrapping to large values, leaving an unsightly "stray line"
on top of the sprite from certain viewing angles/horiz values.
The approach to fix it has two parts: first, the distance is calculated using
float values, preventing the precision loss. Because this doesn't fully prevent
the unwanted lines, the texture coords are clamped to the mininum and maximum
(0 and UINT32_MAX respectively) when calculating them for sprites.
Note that stray lines may still appear at the *bottom* of sprites under certain
circumstances, for example when viewing at a y-flipped sprite from above.
These should be less noticable in real-world usage though.
The feature is guarded by a macro HIGH_PRECISION_SPRITE in case using floating
point or 64-bit integers is undesirable/impossible on some platforms.
git-svn-id: https://svn.eduke32.com/eduke32@3483 1a8010ca-5511-0410-912e-c29ae57300e0
That is, first check if the sprite is in the game world and then if it
already has the desired sector or status number. This doesn't change anything
in our codebase, since the return values of these functions are never examined.
git-svn-id: https://svn.eduke32.com/eduke32@3474 1a8010ca-5511-0410-912e-c29ae57300e0
The usual: declare locals more tightly, const-qualify them where it helps
readability, remove dead code...
git-svn-id: https://svn.eduke32.com/eduke32@3470 1a8010ca-5511-0410-912e-c29ae57300e0
Its only use is to have a actor -> tsprite mapping for the EVENT_ANIMATESPRITE
event and .tspr will be set before it is run.
git-svn-id: https://svn.eduke32.com/eduke32@3448 1a8010ca-5511-0410-912e-c29ae57300e0
Whether a sprite is considered for texel-hitscan is determined on the base
tile number, not the individual animated tile numbers.
git-svn-id: https://svn.eduke32.com/eduke32@3404 1a8010ca-5511-0410-912e-c29ae57300e0
Also, add another flag, signifying that from the editor, also the
"lastwall"s (i.e. the CCW-linked points) should get collected. This is
to signal the editor that their wall lengths should be displayed, too.
git-svn-id: https://svn.eduke32.com/eduke32@3394 1a8010ca-5511-0410-912e-c29ae57300e0
Reproduced as follows (assuming all tiles have texel-hitscan for simplicity):
In E2L5, shoot the opening switch with the shotgun, aiming for the border.
The crash occurs because the *other*, depressed switch tile isn't yet loaded
when we index into its tile storage. Dereferencing 0+small number == BAD!
git-svn-id: https://svn.eduke32.com/eduke32@3364 1a8010ca-5511-0410-912e-c29ae57300e0
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
Also, correct the loadboard() return value checks in premap.c to be
aware of a returned -2 ("wrong map version").
git-svn-id: https://svn.eduke32.com/eduke32@2694 1a8010ca-5511-0410-912e-c29ae57300e0
This should be more correct, since previously, the saved PNGs were way too
contrasty when looked from within a browser. Now, they'll always be
slightly darker than in-game (assuming one has a gamma greater than 1).
git-svn-id: https://svn.eduke32.com/eduke32@2673 1a8010ca-5511-0410-912e-c29ae57300e0
- Make MAXXDIM and MAXYDIM macros be 860 and 490, respectively. tueidj says
max. screen size is 848x480, but there are oob access bugs in the classic
renderer when running with the maximum possible resolution
- don't allocate additional sector/wall storage for Mapster (saves ~16k)
- Add ud.config.UseJoystick = 1 in config.c, but make it conditional on Wii
- remove one comment I no longer believe true, add one TODO comment
git-svn-id: https://svn.eduke32.com/eduke32@2645 1a8010ca-5511-0410-912e-c29ae57300e0
Previously, we checked whether the faded palette has changed (by way of CRC)
and invalidated the textures then unless the preserve flags were set. This
however could lead to wrongly invalidating them under unfortunate circumstances,
e.g. basepal change from CON + tints at the same time before r2620 which
reverted r2232.
Now, only invalidate them if the corresponding preserve flags are clear AND
* the base palette has really changed OR
* the palette CRC changed and we were running on software gamma
The latter means that performance-killing invalidations may still happen on
GL platforms lacking HW gamma (for ATI, it's currently only disabled in 8-bit
fullscreen).
Also have a new global 'basepalreset' to fake a basepal change for
setbrightness(), currently used when changing renderers so that going from
Polymer to Polymost and back again will invalidate the Polymer textures
on the second change, potentially re-applying a basepal highpal. (Still
with me?)
git-svn-id: https://svn.eduke32.com/eduke32@2636 1a8010ca-5511-0410-912e-c29ae57300e0
Because gltexinvalidate*() could be called too often when setgamepalette is used
while having a tint overlaid else. Pending thorough analysis/reworking of the
32-bit mode base palette handling / texture invalidation.
git-svn-id: https://svn.eduke32.com/eduke32@2620 1a8010ca-5511-0410-912e-c29ae57300e0
This has been there since searchbottomwall introduction in r1466.
git-svn-id: https://svn.eduke32.com/eduke32@2604 1a8010ca-5511-0410-912e-c29ae57300e0
Previously, we only set the viewingrange according to the physical screen's
dimensions, but didn't correct yxaspect for a potential non-square pixel
ratio.
git-svn-id: https://svn.eduke32.com/eduke32@2603 1a8010ca-5511-0410-912e-c29ae57300e0
- factor out many identical checks in a convenient function; some messages
may read slightly differently now and tile ranges may be handled more strictly
(error out if one of the limits is invalid)
- factor out two instances of identical (up to one arg) code into
tile_from_truecolpic
- factor out setting picsiz[] and stuff into set_picsizanm
- some checks
- Make "undefmodelof" non-functional and warn.
- in "animtilerange", if the tile difference is >= 64, error out since we
can't store it in picanm[]
git-svn-id: https://svn.eduke32.com/eduke32@2588 1a8010ca-5511-0410-912e-c29ae57300e0
This requires one tweak in drawrooms' umost/dmost setup to prevent oob access.
Specifically, a coordinate difference of 0 is allowed. In the classic renderer,
this would mean a one-pixel (real screen coords) height or width. In Polymost,
it would currently mean a one-pixel height and zero-pixel width, but this might
be subject to change.
git-svn-id: https://svn.eduke32.com/eduke32@2574 1a8010ca-5511-0410-912e-c29ae57300e0
(That is, the base shade table.) Before, we allocated each palookup buffer.
For a vanilla setup, this means that we're now saving 224*32*256 ~= 1.8 megs,
which might be interesting for low-memory gadgets.
git-svn-id: https://svn.eduke32.com/eduke32@2571 1a8010ca-5511-0410-912e-c29ae57300e0
First, it's unlikely in our day and age. Second, they're always free'd at the end,
so allocache'ing them is incorrect.
git-svn-id: https://svn.eduke32.com/eduke32@2570 1a8010ca-5511-0410-912e-c29ae57300e0
Also,
- use this in game.c and astub.c palookup loading code
- when makepalookup() is passed a 0 palnum, return early. This means that
'fogpal' will silently fail when attempting to change pal 0.
- in 'makepalookup' DEF command, error out if passed a pal of 0.
git-svn-id: https://svn.eduke32.com/eduke32@2569 1a8010ca-5511-0410-912e-c29ae57300e0
Alongside, these make into into the header:
- the 'tokenlist' type (a typedef'd struct)
- the T_EOF and T_ERROR enumeration values
git-svn-id: https://svn.eduke32.com/eduke32@2549 1a8010ca-5511-0410-912e-c29ae57300e0
- Help window text cleaned and made more consistent between game and editor
- Added help entry for "-clipmap"
- Log text for using CON, DEF, and RTS files has been made consistent
- All instances of '%s' have been replaced with \"%s\" because ' is a valid filename character. (At least on Windows.)
git-svn-id: https://svn.eduke32.com/eduke32@2538 1a8010ca-5511-0410-912e-c29ae57300e0
There are instances where oob picnums may propagate to that function, so
protect it. The digitanumber[z] bound check is actually made more permissive,
but could also just as well be removed now.
git-svn-id: https://svn.eduke32.com/eduke32@2533 1a8010ca-5511-0410-912e-c29ae57300e0
This makes the differences in these codes stand out much more clearly.
git-svn-id: https://svn.eduke32.com/eduke32@2526 1a8010ca-5511-0410-912e-c29ae57300e0
We shouldn't assume a particular bytes-per-line value and use ylookup[] instead.
Specifically, windowed modes on Windows use a frame buffer that always has odd
x dimension.
git-svn-id: https://svn.eduke32.com/eduke32@2505 1a8010ca-5511-0410-912e-c29ae57300e0
- in Mapster, pre-form the default 10 clip map names before returning from
G_CheckCommandLine() so it gets loaded even if we passed no cmdline args.
- malloc + strlen + strcpy --> strdup
- don't need to spank dead variables ;)
- we may call calloc with zero size, which isn't bad by itself, but asserting
for non-null afterwards is. Allocs of 0 are implementation-defined, and may
well return a null pointer (C99 7.20.3).
git-svn-id: https://svn.eduke32.com/eduke32@2502 1a8010ca-5511-0410-912e-c29ae57300e0
Gives a couple more fps for scenes where much screen estate is covered by
stuff, like when holding the devastator.
git-svn-id: https://svn.eduke32.com/eduke32@2499 1a8010ca-5511-0410-912e-c29ae57300e0
With the same setup as before, a screen-filling translucent wall (with nothing
drawn behind it) renders at about 7 fps faster (from 60-something fps initially)
git-svn-id: https://svn.eduke32.com/eduke32@2498 1a8010ca-5511-0410-912e-c29ae57300e0
These two functions draw a vertical line 4 neighboring pixels at a time.
This gives a significant speed boost for a full screen solid and masked wall
scene for x86_64 (where we have plenty of registers), about 60 --> 76 fps.
git-svn-id: https://svn.eduke32.com/eduke32@2497 1a8010ca-5511-0410-912e-c29ae57300e0
Also, a very minor change in the con/def module code. (int --> int32_t)
git-svn-id: https://svn.eduke32.com/eduke32@2495 1a8010ca-5511-0410-912e-c29ae57300e0
Previously, if the sprite turned really out to be in void space, either freelist
inconsistency (before the list rewrite) or oob access (now) would happen.
Also add an bound-checking assert() for insertsprite's sectnum argument (it's not
a bound check!)
git-svn-id: https://svn.eduke32.com/eduke32@2480 1a8010ca-5511-0410-912e-c29ae57300e0
New engine variable 'int32_t Numsprites', not yet saved into savegames
or mapstates. (The capitalization is to distinguish it from the often-used
'numsprites' locals or structure member names.
In the editor, get rid of updatenumsprites().
git-svn-id: https://svn.eduke32.com/eduke32@2478 1a8010ca-5511-0410-912e-c29ae57300e0
Previously, the lists starting at headspritestat[MAXSTATUS] and
headspritesect[MAXSECTORS] were both used as sprite freelists and were always
in complete synchrony. Now, make only the statnum list keep the free sprites.
This way, it has no CON compatibility implications because
headspritesect[MAXSECTORS] is inaccessible there. Leave the array at its
original size for now.
git-svn-id: https://svn.eduke32.com/eduke32@2477 1a8010ca-5511-0410-912e-c29ae57300e0
The major outside-visible change is that this fixes the sound cutoff bugs that
happened because newly-spawned sprites took the place of those whose sounds
had not yet finished playing.
Besides, there are these changes:
- remove deletesprite{sect,stat}
- we have a new engine variable 'tailspritefree' that keeps track of the
sprite freelist tail
- we need to store it in savegames and mapstates, so bump the savegame
minor version
git-svn-id: https://svn.eduke32.com/eduke32@2470 1a8010ca-5511-0410-912e-c29ae57300e0
This is simply done by using the two list helper functions defined earlier
instead of a deletespriteX/insertspriteX pair.
git-svn-id: https://svn.eduke32.com/eduke32@2469 1a8010ca-5511-0410-912e-c29ae57300e0
Factor out two helper functions, do_deletesprite{sect,stat}
and do_insertsprite_at_headof{sect,stat}.
git-svn-id: https://svn.eduke32.com/eduke32@2466 1a8010ca-5511-0410-912e-c29ae57300e0
These operations aren't executed THAT often to warrant exposing four internal
functions. Besides, I'll be hacking on them and need everything laid out
cleanly. Should somebody complain, they can go change them to __fastcall or
something.
git-svn-id: https://svn.eduke32.com/eduke32@2465 1a8010ca-5511-0410-912e-c29ae57300e0
In changesprite{stat,sect}, don't check for deletesprite{stat,sect} failure,
because the only way it can fail was already checked for above. So, this is
essentially dead code elimination.
git-svn-id: https://svn.eduke32.com/eduke32@2462 1a8010ca-5511-0410-912e-c29ae57300e0
- forgot a glogy --> logy in a-c.c
- comment out stretchhline and slopevlin2 in a.nasm, the former also in a-c.c
- make transmaskvline2 use a uintptr_t where appropriate
git-svn-id: https://svn.eduke32.com/eduke32@2448 1a8010ca-5511-0410-912e-c29ae57300e0
When drawing from inside the mirror, there may be no 'bunches' (BUILD lingo,
not TROR ones) collected, but following code used the first one unconditionally.
git-svn-id: https://svn.eduke32.com/eduke32@2427 1a8010ca-5511-0410-912e-c29ae57300e0
The apparent horizon (in units proportional to pixels by a constant factor)
was being calculated without normalizing to viewingrange, resulting a
discrepancy between the drawn and actual up/down angle with non-default
viewingranges (e.g. with r_usenewaspect=1, or when setting it from setaspect).
This also means that the center-of-aim will now be the same regardless of
the aspect.
This fixes many derived bugs:
* inconsistency w/ crosshair when shooting a gun and aiming up/down (obviously)
* bugs resulting from being able to look up/down too far (garbage non-slope
texture-mapping and viewing BIGORBIT skies above the borders in classic).
Note: mods that had workaround logic for this bug will have to remove it...
git-svn-id: https://svn.eduke32.com/eduke32@2414 1a8010ca-5511-0410-912e-c29ae57300e0
This has no measureable difference. Oh well, maybe it benefits weaker
machines, since the generated loop code should definitely be prettier.
git-svn-id: https://svn.eduke32.com/eduke32@2408 1a8010ca-5511-0410-912e-c29ae57300e0
This doesn't give much, maybe 0.5 fps more, probably because the
loop body is pretty long.
git-svn-id: https://svn.eduke32.com/eduke32@2406 1a8010ca-5511-0410-912e-c29ae57300e0
(Classic renderer). We don't need 64-bit integers; also use the nice
asm version of divscale32() if possible.
git-svn-id: https://svn.eduke32.com/eduke32@2390 1a8010ca-5511-0410-912e-c29ae57300e0
This was discovered because viewscreens (TILE_VIEWSCR) ceased being drawn
with the MAXTILES increase (reported by Hank, who also did the bisect).
git-svn-id: https://svn.eduke32.com/eduke32@2376 1a8010ca-5511-0410-912e-c29ae57300e0
That is, everyplace a user input is to be converted. The only remaining
instance of atoi() is now atoi(s_buildDate).
git-svn-id: https://svn.eduke32.com/eduke32@2374 1a8010ca-5511-0410-912e-c29ae57300e0
Internally, the last argument to neartag is now a pointer to a function
int32_t (*blacklist_sprite_func)(int32_t i),
which is supposed to return 1 if sprite[i] should NOT be considered for hitting.
This is now used in the hard-coded neartag() calls in sector.c, but not in any
way in CON (there's neither a C blacklist function provided, nor is there a
possibility to define one in CON). There, all sprites with picnums >=1 and <=10
(i.e. the effectors) will be blacklisted. This remedies problems where such
sprites would get in the way of switches.
Note that a whitelist approach (only consider a predefined set, namely those
picnums which will be checked afterwards) has back-compatibility implications
since people may have used e.g. lotagged window sprites to cover a switch.
Also, the >=1 to <=10 range is [sic] (the static, not dynamic values are used),
since anyone redefining effector picnums is clearly out of their mind.
git-svn-id: https://svn.eduke32.com/eduke32@2373 1a8010ca-5511-0410-912e-c29ae57300e0
The bulk are whitespace changes; the only exception is a
"if (expr) { stmt; }" --> "if (expr) stmt;"
git-svn-id: https://svn.eduke32.com/eduke32@2353 1a8010ca-5511-0410-912e-c29ae57300e0
The reason was that drawmasks(), which was where the resetting of the fake
RoR textures happened under Polymer, can be called from polymer_displayrooms()
when mirrors are present. I was assuming that drawmasks() was only ever called
after the 'main' drawrooms and that hence the sequence of fake RoR tile tweaking
was set, reset, set, reset, ... which it was not.
Now, do the resetting explicitly after every drawmasks() in the editor.
git-svn-id: https://svn.eduke32.com/eduke32@2350 1a8010ca-5511-0410-912e-c29ae57300e0
I find this cleaner for two reasons. First, lotags won't get in the way of
neartag(), so that doors and switches near constrained TROR walls can be
pushed. Second, this removes the information leak so that CON coders aren't
tempted to read that values directly before a proper API for that comes along.
When writing out a map in-game (e.g. with dndebug), restore the respective
members so that it can be loaded in the editor again.
git-svn-id: https://svn.eduke32.com/eduke32@2349 1a8010ca-5511-0410-912e-c29ae57300e0
getzrange() returns the floor rather than the sprite if their heights are
equal. Now, make an exception for extended floors (analogously, ceilings).
git-svn-id: https://svn.eduke32.com/eduke32@2347 1a8010ca-5511-0410-912e-c29ae57300e0
- guard cansee() against negative sectnums (return 0 immediately), since
it's often called with the player sectnum as one argument
- in resetpspritevars(), don't inset APLAYER sprite if sectnum < 0, which
can happen if a map is started in void space accidentally (e.g. from
the editor)
- two checks before accessing sector[] with a player sectnum
git-svn-id: https://svn.eduke32.com/eduke32@2342 1a8010ca-5511-0410-912e-c29ae57300e0
Internally, there's a new function fade_screen_black() that implements the
fading more efficiently than calling rotatesprite for classic, and uses
tile 0 (assumed to have at least 64x32 size) in the GL modes.
The black background of the user map selector is still done with rotatesprite
and tile BLANK in every renderer.
git-svn-id: https://svn.eduke32.com/eduke32@2312 1a8010ca-5511-0410-912e-c29ae57300e0
It looks like GCC doesn't honor the 'used' attribute with LTO. This is
"fixed" by declaring the variables in question with external linkage
(i.e. removing the 'static'). I consider such behavior a GCC bug, though.
git-svn-id: https://svn.eduke32.com/eduke32@2286 1a8010ca-5511-0410-912e-c29ae57300e0
This may fix compilation for optimized builds with GCC or clang where
the compiler would otherwise decide that those symbols are unused.
git-svn-id: https://svn.eduke32.com/eduke32@2271 1a8010ca-5511-0410-912e-c29ae57300e0
If enabled, this makes the following arrays be allocated statically:
spriteext, spritesmooth, sector, wall, sprite, tsprite, while
necessarily disabling the clipshape feature (because it relies on
setting sector/wall to different malloc'd block temporarily).
To compile, pass DEBUGANYWAY=1 in addition to RELEASE=0 to 'make',
and it's really only useful with CC=clang, of course.
git-svn-id: https://svn.eduke32.com/eduke32@2270 1a8010ca-5511-0410-912e-c29ae57300e0
- fix one bound-checking line
- rewrite two lines in astub.c to potentially not overflow an int16
- make tiletovox[] an array of int16's
git-svn-id: https://svn.eduke32.com/eduke32@2266 1a8010ca-5511-0410-912e-c29ae57300e0
Always malloc that buffer. This allows us to remove suckcache() from
cache1d.c, which I believe to be buggy (see comments in the source).
git-svn-id: https://svn.eduke32.com/eduke32@2261 1a8010ca-5511-0410-912e-c29ae57300e0
- 'whitecol' was defined in the engine and in build.c, use only the engine one
- make cachesize, artsize, artversion static in engine.c
- undo some formatting havoc presumably done by astyle
git-svn-id: https://svn.eduke32.com/eduke32@2260 1a8010ca-5511-0410-912e-c29ae57300e0
It is likely that this is the value it used to have at some point, because
the MAXTILEFILES macro equals 256 and is as old as the Duke3D source.
loadpics() now refuses to load an ART file with localtilestart or localtileend
out of bounds, or if localtileend<=localtilestart (i.e. no tiles in ART file, or
nonsense). Also, on 'invalid art file version', continue instead of returning.
Note: this does not increase the maximum number of tiles, which is still 15360,
it only gives a bit more freedom to arrange them (well, into more art files).
Also, I don't see what anyone keeps off from packing any number of tiles (from
1 to 15360) into an art file. Old EDITART limits?
git-svn-id: https://svn.eduke32.com/eduke32@2259 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
'frequently' isn't such a good idea. Assume an actor constantly changes the
palette to some value and you're attacked by a newbeast at the same time. Then
the pain tinting would be reset each time the actor's code is run. This commit
adds a new flag 16 to setbrightness(), meaning "don't reset the fade tinting".
Its only use right now is from CON's setgamepalette command (and there, always).
The change is done in the engine and thus affects all platforms.
git-svn-id: https://svn.eduke32.com/eduke32@2225 1a8010ca-5511-0410-912e-c29ae57300e0
color-inversed shots. For both PNG and TGA, change the way they're
done in 8-bit mode: instead of XORing every byte with 15, save the
inverse palette (each component taken 255-x).
git-svn-id: https://svn.eduke32.com/eduke32@2219 1a8010ca-5511-0410-912e-c29ae57300e0
instead of shorts. This fixes their values' overflow in AMC TC megabase and
probably a couple of other large maps.
git-svn-id: https://svn.eduke32.com/eduke32@2216 1a8010ca-5511-0410-912e-c29ae57300e0
32- and 64-bit platforms. Also, make struct type actor_t also have a common
size of 128 bytes. New code currently disabled and #ifdef'd for comparison.
This requires certain t_data[] entries ([1]: move ptr, [4]: action ptr and
[5]: ai ptr with actors) to be converted to script offsets instead of pointers,
breaking savegame and net packet compatibility (we could in theory try hard not
to, but it would be too much trouble).
git-svn-id: https://svn.eduke32.com/eduke32@2185 1a8010ca-5511-0410-912e-c29ae57300e0
Actors are always moved such that _they_ clip against blocking sprites, even
if their blocking bit is clear. Setting the new bit make them not clip against
anything. The promary use of this is for decorative moving sprites that are
spawned in masses, such as rain or snow.
git-svn-id: https://svn.eduke32.com/eduke32@2184 1a8010ca-5511-0410-912e-c29ae57300e0
already have MAXSPRITESONSCREEN of them, return 1 to signal that the caller
should break out of the loop.
git-svn-id: https://svn.eduke32.com/eduke32@2183 1a8010ca-5511-0410-912e-c29ae57300e0
(getzrange, hitscan, clipmove, drawmapview).
They're reproducible with DNE1.3D; Since these angle values most likely come
from CON code, my suggestion would be to bit-and all values representing angles
with 2047 when setting the from CON, but I'd have to think about potential
side-effects of doing this.
git-svn-id: https://svn.eduke32.com/eduke32@2170 1a8010ca-5511-0410-912e-c29ae57300e0
that bunches and nextwall links are restores, too. Now, to coalesce two
TROR maps (e.g. for a CBP), one could
do for i allsectors, sethighlightsector i 1
on the console, and then load the 'other' map to copy over the contents
of the first, including all TROR stuff. Note that neither selecting
all sectors with RAlt, nor duplicating them with Insert would lead to
the desired effect (yet).
Internally,
- yax_setbunch() now has different behavior for bunchnums -1, -2 and -3
(it either clears the nextwalls or not)
- build.c has a helper function free_n_ptrs(). This could be handy in
other situations where many blocks of memory must be allocated
consecutively and freed in case of failure
git-svn-id: https://svn.eduke32.com/eduke32@2136 1a8010ca-5511-0410-912e-c29ae57300e0
