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
