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
It's hard to call this a fix, since ideally, buffer sizes like these would be
only as large as needed in the worst case.
git-svn-id: https://svn.eduke32.com/eduke32@3880 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
The latter checked with #defined HAVE_GTK2, which is probably not correct
for every platform.
In builds without a startup window, the periods get mingled with stdout
output otherwise.
git-svn-id: https://svn.eduke32.com/eduke32@3827 1a8010ca-5511-0410-912e-c29ae57300e0
In 3D mode, Alt+F now only attempts to set the first wall of the aimed at
wall, not collecting upper/lower neighbors. For this, press Shift+Alt+F.
In 2D mode, they are always collected.
git-svn-id: https://svn.eduke32.com/eduke32@3825 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
This fixes the case marked with the silver letter C in test_tileoffsets.map.
The orientation of the sprites is correct (matches classic) as far as I can
see, there are now only problems with translation.
git-svn-id: https://svn.eduke32.com/eduke32@3776 1a8010ca-5511-0410-912e-c29ae57300e0
Also, add some defines for sprite cstats to build.h (SPR_*) and use them.
git-svn-id: https://svn.eduke32.com/eduke32@3775 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
- factored out: tweak_sboardfilename(), menuselect_try_findlast()
- quickloading a map now doesn't require loading one first
- the usual
git-svn-id: https://svn.eduke32.com/eduke32@3749 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
The visibility calculation relies on the distance, which might not be entirely
accurate in rotatesprite, so maybe it'll be too dark in some cases.
git-svn-id: https://svn.eduke32.com/eduke32@3741 1a8010ca-5511-0410-912e-c29ae57300e0
TODO: figure out wtf is wrong with rotatesprite, linear filtering.
git-svn-id: https://svn.eduke32.com/eduke32@3737 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
In those Clang versions, -fcatch-undefined-behavior was replaced by
-fsanitize=<what>. For Clang 3.2, we enable the address sanitizer
and for 3.3 also the miscellaneous undefined behavior one.
Currently, there's no version auto-detection from the Makefiles, it's
set to 3.3 and the others are commented out.
git-svn-id: https://svn.eduke32.com/eduke32@3716 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
Specifically, in GL modes, and if the CHAINGUN is not replaced by a model,
- draw the upper part twice: first, two screen pixels * weapon scale lower,
then at the original position
- reverse the previous order: draw the upper part first, then the lower part
This is much preferable to the previous engine-side hack, and to my eye,
it looks perfect now.
git-svn-id: https://svn.eduke32.com/eduke32@3695 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
(Note: We are still vulnerable to crashes here (and likely in other places), but you have (4096-16) extra characters to work with. We should consider replacing many uses of Bsprintf with Bsnprintf.)
git-svn-id: https://svn.eduke32.com/eduke32@3669 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
Toggled with Ctrl+Shift+[KP-]. Variable 'headlight_range' controls its range.
For the implementation, a new event EVENT_PREDRAW3DSCREEN was added.
git-svn-id: https://svn.eduke32.com/eduke32@3648 1a8010ca-5511-0410-912e-c29ae57300e0
- Don't attempt to play an ANM file if it is empty (warn) or too short (error).
- If failing to read IVF file header or initializing VPX codec, don't play ANM.
- Return early from gltexapplyprops() if not in GL modes.
git-svn-id: https://svn.eduke32.com/eduke32@3628 1a8010ca-5511-0410-912e-c29ae57300e0
While the functionality was already internally in place for gametext as one of two hacks using ROTATESPRITE_MAX (the other still used by minitext_() to align with the statusbar) we must codify a bit in the engine for safe external use. (Otherwise, ROTATESPRITE_MAX could/would theoretically increase and leave modders high and dry.)
(Dev note: In G_DrawTXDigiNumZ(), ROTATESPRITE_MAX was used to bitshift the value used to calculate digit spacing for no reason I can ascertain other than to introduce rounding errors into the zoom/textscale calculations. It was never used anywhere, so I removed it.)
Bonus: The scaling code for digitalnumberz and gametextz has been modified so that the spacing is no longer affected by rounding errors. Try animating the zoom value and compare how the text used to jump but now does not.
git-svn-id: https://svn.eduke32.com/eduke32@3608 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
... into a macro MFLAGS_NOCONV(m). Since it currently expands to (0), some dead
code will be eliminated.
Introduce a "compilation option" macro DO_MD2_MD3_CONV in mdsprite.c.
git-svn-id: https://svn.eduke32.com/eduke32@3588 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
- Make _buildargv[_buildargc] NULL.
- With SDL layer, pass argv and argc directly and get rid of _build* ones.
- Add tilesiz* to dynsymlists.
git-svn-id: https://svn.eduke32.com/eduke32@3573 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
If m32script gamevar "move_by_one" is nonzero, the some keys move the
"player arrow" by increments of 1:
- Without SHIFT: LEFT/RIGHT absolute x, DOWN/UP absolute y, A/Z absolute z.
- With SHIFT: DOWN/UP (unbounded!) horiz, LEFT/RIGHT angle.
This can be useful to debug renderer bugs that show a high sensitivity to the
exact location ("are transient in space").
git-svn-id: https://svn.eduke32.com/eduke32@3509 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
Most of them are already aligned to their natural boundaries, so lowering
the alignment to 1 byte can only worsen things by making the C compiler
generate poorer (unaligned access) code for some platforms.
The layout of structures is not specified by the C Standard, but is rather
given by a particular platform + toolchain's ABI (application binary interface).
Most ABIs follow the expected pattern "alignment of scalars is their size,
alignment of arrays is that of its element type, alignment of structs is the
maximum alignment of its members". A couple of links to particular ABIs are
given in build.h.
Problems are expected with archs that care about unaligned access when a pointer
to a non-packed struct is taken that resides in a packed aggregate, but these
uses should be weeded out (I'm not sure if there are any in our codebase).
The following types are affected, only hitdata_t changes its size:
sectortype, walltype, spritetype, spriteext_t, spritesmooth_t,
struct validmode_t, picanm_t, palette_t, vec2_t, vec3_t, hitdata_t.
git-svn-id: https://svn.eduke32.com/eduke32@3455 1a8010ca-5511-0410-912e-c29ae57300e0
