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
Previously, actor[].shootzvel (implementation detail, not available to CON)
was checked, and if it was !=0, that was the overridden velocity. The value
0 meant "hardcoded, projectile-dependent velocity". But that neccesiated a
hack where if zvel 0 was passed and really meant, it needed to be set to
1 instead. Now we have A_ShootWithZvel() taking an additional last argument
plus a macro SHOOT_HARDCODED_ZVEL permissible for that argument.
git-svn-id: https://svn.eduke32.com/eduke32@3465 1a8010ca-5511-0410-912e-c29ae57300e0
actors.h: remove 'packed' from projectile_t, tiledata_t. In tiledata_t,
make .cacherange member an int32_t so that the following member
"projectile_t defproj" is aligned on a 4-byte boundary.
player.h: remove 'packed' from playerspawn_t, DukeStatus_t, input_t.
In Lunatic, correct packing attribute of the base type of the unrestricted
actor_t and DukePlayer_t pointer types (the declaration was used without
Bump BYTEVERSION.
git-svn-id: https://svn.eduke32.com/eduke32@3458 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
And const them appropriately. Also remove #if 0'ed code related to an MSVC
pragma.
git-svn-id: https://svn.eduke32.com/eduke32@3451 1a8010ca-5511-0410-912e-c29ae57300e0
Meaning that only *ettsprite[THISACTOR] makes sense from CON. It did before
too, because .tspr was set before each event run (and not before all runs),
only that it was never nulled, which was kind of untidy.
git-svn-id: https://svn.eduke32.com/eduke32@3450 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
The m32script variable 'showrespawn_always' toggles whether the respawned picnum
is shown unconditionally instead of only when aimed at (and locked onto the
RESPAWN sprite) in 3D mode.
Cool idea by Micky C.
NOTE: sometimes doesn't work because of a bug in the m32script interpreter.
git-svn-id: https://svn.eduke32.com/eduke32@3447 1a8010ca-5511-0410-912e-c29ae57300e0
Pass types via ffi.typeof() instead of declaring them in the
global namespace when possible.
git-svn-id: https://svn.eduke32.com/eduke32@3437 1a8010ca-5511-0410-912e-c29ae57300e0
Use a new flag to mark hard-coded enemies, not SPRITE_BADGUY.
This fixes an issue where in E1L4, a pigcop would appear in the area
you have to crawl under shrunk. Thanks to LLCoolDave1 for pinpointing
the range of relevant revisions.
git-svn-id: https://svn.eduke32.com/eduke32@3426 1a8010ca-5511-0410-912e-c29ae57300e0
Whenever it should be not, STRIP is set to the empty string.
This fixes the Lunatic RELEASE=1 build.
git-svn-id: https://svn.eduke32.com/eduke32@3422 1a8010ca-5511-0410-912e-c29ae57300e0
The pixel doubling now only applies to the area where the world scene is drawn,
i.e. it may be smaller than the physical screen / WM window size. The optimized
version is slightly faster than for non-doubled pixels for me (optimized build),
but see code for caveats. Some other minor issues:
- won't work when the world is drawn from demo cameras (and offscreen, but that
matters less)
- will leave a few pixels empty when running with x resolutions not evenly
divisible by 4
git-svn-id: https://svn.eduke32.com/eduke32@3421 1a8010ca-5511-0410-912e-c29ae57300e0
In CON, the bit is still always cleared for user-defined gamevars.
git-svn-id: https://svn.eduke32.com/eduke32@3417 1a8010ca-5511-0410-912e-c29ae57300e0
- more predefined vars
- fix recursive states and ones with a stray "else" before the end
git-svn-id: https://svn.eduke32.com/eduke32@3409 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
* Make the "classic status bar fullscreen viewport" mode accessible
in classic too.
* Make range of status bar scale 36..100
* Update ud.statusbarmode when executing OSD command r_size (ud.screen_size).
NOTE: ud.statusbarmode is considered internal. Don't use from CON!
* Make sure 1) loading any configuration and 2) menu bars work correctly.
(The "classic status bar fullscreen viewport" mode will never be restored
though because ud.statusbarmode isn't handled by the OSD var system).
git-svn-id: https://svn.eduke32.com/eduke32@3402 1a8010ca-5511-0410-912e-c29ae57300e0
One use was in determining the ray vector for the mouse-aiming hitscan
in the editor. Unfortunately, the change doesn't make it any less broken
in Polymost, even if the two instances were out of sync.
git-svn-id: https://svn.eduke32.com/eduke32@3401 1a8010ca-5511-0410-912e-c29ae57300e0
If enabled, dragging wall vertices will correct the xrepeat after the
mouse button is released, so that the pre-drag absolute stretching is
restored.
git-svn-id: https://svn.eduke32.com/eduke32@3398 1a8010ca-5511-0410-912e-c29ae57300e0
- Run it twice, since the first one is wrong.
- Warn when attempting to align based on a top-oriented wall. When the
sequence of walls to align has "windows", only the bottom parts will
be correct.
- Make the modifiers actually useful:
* Pressing SHIFT aligns at most one wall, remove the old CTRL modifier.
* The rest is as before: ALT makes the walls have (approximately) equal
texture stretching, ['] (quote) aligns the immediate TROR-nextwalls.
git-svn-id: https://svn.eduke32.com/eduke32@3396 1a8010ca-5511-0410-912e-c29ae57300e0
Also, factor out 2x dup'd code of insertsprite() into do_insertsprite()
and add searchwall-displaying code into package/samples/a.m32.
git-svn-id: https://svn.eduke32.com/eduke32@3395 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
This is done by introducing an additional internal bit, meaning
"play only one instance". It is set for all sounds which have bit 1
("repeat in the sound system") set at definesound time, but not those
that set bit 1 temporarily (see r3336).
git-svn-id: https://svn.eduke32.com/eduke32@3393 1a8010ca-5511-0410-912e-c29ae57300e0
Also, rewrite comparison to the non-tint in astub.c to be even less hackish.
git-svn-id: https://svn.eduke32.com/eduke32@3387 1a8010ca-5511-0410-912e-c29ae57300e0
- Stop using memcache on some other failure paths, particularly when
failing to read from the on-disk texcache.
- Factor out cache reading code (3x).
- Fix endianness issues affecting big-enadian systems (one introduced by
r3382, one existing before). Comment each B_LITTLE32 with whether we're
converting from native to on-disk (little) endianness or back.
git-svn-id: https://svn.eduke32.com/eduke32@3386 1a8010ca-5511-0410-912e-c29ae57300e0
This obviously won't help performance as the scene has still to be drawn at
the original resolution, but it's better than the draw-to-tile hack.
git-svn-id: https://svn.eduke32.com/eduke32@3378 1a8010ca-5511-0410-912e-c29ae57300e0
The SDL and Windows layers had slightly different code: the latter would
dereference a NULL pointer if stdout.txt failed being write-opened.
git-svn-id: https://svn.eduke32.com/eduke32@3377 1a8010ca-5511-0410-912e-c29ae57300e0
When reaching wall limits, it is possible that only some circle points will
be inserted and the result is left unfinished.
git-svn-id: https://svn.eduke32.com/eduke32@3376 1a8010ca-5511-0410-912e-c29ae57300e0
On the C side, zrange, angrange and autoaimang are represented as
DukePlayer_t members then.
git-svn-id: https://svn.eduke32.com/eduke32@3366 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
The diff may look daunting, but it's clear what is changed with
git diff (...) --color-words='[a-zA-Z0-9_]+|[^[:space:]]' -b
git-svn-id: https://svn.eduke32.com/eduke32@3361 1a8010ca-5511-0410-912e-c29ae57300e0
Factoring out 2x almost duplicated code into {P,A}_PostFireHitscan().
git-svn-id: https://svn.eduke32.com/eduke32@3360 1a8010ca-5511-0410-912e-c29ae57300e0
The code is duplicated with small changes for the hardcoded and custom
projectiles.
Adding local functions P_PreFireHitscan(), A_PreFireHitscan() and
Proj_MaybeAddSpread().
git-svn-id: https://svn.eduke32.com/eduke32@3358 1a8010ca-5511-0410-912e-c29ae57300e0
In Lunatic-only build, also always allocate the first 128 quotes.
git-svn-id: https://svn.eduke32.com/eduke32@3356 1a8010ca-5511-0410-912e-c29ae57300e0
Preventing a continuously growing stack top and inevitable program termination.
Also, commonize the error handling to live on the engine side.
git-svn-id: https://svn.eduke32.com/eduke32@3352 1a8010ca-5511-0410-912e-c29ae57300e0
If you see any weird behavior in synthesis builds after this change, please
let Plagman know!
git-svn-id: https://svn.eduke32.com/eduke32@3348 1a8010ca-5511-0410-912e-c29ae57300e0
FLAC source from git commit 0920bc1ffb07f038b317e7e8056509fe0e4b680e, patched by me.
Windows libFLAC.a built using i686-MinGW-w64 and x86_64-MinGW-w64.
HUGE thanks to rhoenie for building the Mac fat library (ppc, i686, x86_86).
git-svn-id: https://svn.eduke32.com/eduke32@3335 1a8010ca-5511-0410-912e-c29ae57300e0
* Renamed source/jaudiolib/third-party/mingw32 to source/jaudiolib/third-party/Windows.
* Moved source/jaudiolib/third-party/Windows/include to source/jaudiolib/third-party/common/include to use both on Windows and Apple.
* Deleted Apple/lib/include/{ogg,vorbis}/, see previous point.
* Deleted Apple/lib/libvorbisenc.a, 6MB saved.
* Moved Apple/lib/lib{ogg,vorbis,vorbisfile}.a to source/jaudiolib/third-party/Apple/lib, where they belong.
* Moved source files in Apple/ to source/, where they belong. (SDLMain.[mh] stay.)
* Deleted source/jaudiolib/third-party/{ogg,vorbis}.framework, not used any more.
* Renamed "StartupWinController*" to "startosx*".
git-svn-id: https://svn.eduke32.com/eduke32@3334 1a8010ca-5511-0410-912e-c29ae57300e0
In the normal game, these arrays are conceptually [MAX_WEAPONS][MAXPLAYERS],
allocated as CON per-player gamevars (e.g. WEAPONx_WORKSLIKE).
For Lunatic, they are replaced with
weapondata_t g_playerWeapon[MAXPLAYERS][MAX_WEAPONS].
git-svn-id: https://svn.eduke32.com/eduke32@3328 1a8010ca-5511-0410-912e-c29ae57300e0
Specifically, have a weapondata_t type mimicking the aplWeapon* arrays.
Keep a list weapondefaults[] which undergoes some static->dynamic tweaks
and then makes its way to the WEAPONx_XXX per-player gamevars.
git-svn-id: https://svn.eduke32.com/eduke32@3327 1a8010ca-5511-0410-912e-c29ae57300e0
- Rewrite the "clear background" routine in a no-brainer way instead of
juggling around with rotatesprite(). Make it common to game+editor.
Expose glRectd to glbuild.
- Don't stop OSD text line drawing when encountering a non-printable char.
Instead, treat it as space.
- In OSD_SetTextMode(), don't use swaplong (which really swaps 32-bit ints)
to swap pointers. Write an analogous "swapptr" instead.
- When changing from/to OSD, don't inject a pause key. This *might* have been
the cause of the reported pausing problems.
- clean up the code...
(Yes, this commit throws together too much stuff. I suck sometimes. :P)
git-svn-id: https://svn.eduke32.com/eduke32@3321 1a8010ca-5511-0410-912e-c29ae57300e0
Rotation-fixing happens for a couple of hard-coded statnums that presumably
never move (DEFAULT, STANDABLE, FX, FALLER, LIGHT), but for actors it wouldn't
make sense since the common case is that they do move. For this reason, bit 4
was introduced in r1934. The position of such useractors will not diverge
due to error roundoff accumulation in rotating sectors (SE0, train).
git-svn-id: https://svn.eduke32.com/eduke32@3316 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
That is, everything concerning orientation. Previously, it was wrongly
the bitwise NOT of these bits that got taken over. In particular, if bit
2 (swap bottom walls) would get pasted, ridiculousness could ensue.
git-svn-id: https://svn.eduke32.com/eduke32@3306 1a8010ca-5511-0410-912e-c29ae57300e0
Implemented using GL_LINEAR fog. The only source of difference (besides the
obvious indexed vs. true color) should now be the distance constant, which
still had to be determined experimentally. Polymer implements this mode in
its fog fragment program part.
Parallaxed skies are always drawn with full visibility, I'm not sure if there
are any maps that expect otherwise.
Also, accidentally committed: factor out initialization code from
polymost_printext256() into gen_font_glyph_tex(), small game.c changes.
git-svn-id: https://svn.eduke32.com/eduke32@3301 1a8010ca-5511-0410-912e-c29ae57300e0
It was caused by the definition of c_dfDIJoystick using literal 24 and 16 values in place of sizeof(DIDATAFORMAT) and sizeof(DIOBJECTDATAFORMAT), which include pointers. On 64-bit, the values end up being 32 and 24, causing a discrepancy in which DIERR_INVALIDPARAM was thrown.
1b1e05db06/diffs
git-svn-id: https://svn.eduke32.com/eduke32@3300 1a8010ca-5511-0410-912e-c29ae57300e0
- Updated to use StackWalk64 function call, requiring some addition of headers from MinGW-w64 to compile with MinGW.
- Code added to support 64-bit executables: functionality added and one warning fixed.
- New DLL binaries compiled using i686-MinGW-w64 and x86_64-MinGW-w64. (Oddly, the DLL built with MinGW is 5 MB while MinGW-w64's is 1 MB.)
git-svn-id: https://svn.eduke32.com/eduke32@3299 1a8010ca-5511-0410-912e-c29ae57300e0
This also means that the "r_shadescale_unbounded 0" option will work
in Polymer (except on models).
git-svn-id: https://svn.eduke32.com/eduke32@3286 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
