It does not depend on the "swap bottom wall parts" bit being set.
The fix is by matching up the related code with Polymost.
git-svn-id: https://svn.eduke32.com/eduke32@5230 1a8010ca-5511-0410-912e-c29ae57300e0
For this, add a setaspect_new() setup/restore pair in M32_DrawRoomsAndMasks()
like for G_DrawRooms(). With this, changing viewingrange/aspect via m32script
(in a.m32: [7] -- [9] on the upper row) can only be done in r_usenewaspect 0,
though.
git-svn-id: https://svn.eduke32.com/eduke32@5182 1a8010ca-5511-0410-912e-c29ae57300e0
artfile { file "whatever.art" } // loads whatever.art just as if it had been named TILES020.ART
artfile { file "whatever.art" tile 2000 } // loads whatever.art starting at index 2000 instead of the tilestart value contained within it
This is useful because ART files will load faster than images loaded through tilefromtexture (which must undergo a color matching process), and because tiles making use of palette indices which have duplicate colors in the stock Duke 3D palette but not in other palettes (such as the 3D Realms screen) are negatively affected by the aforementioned process.
git-svn-id: https://svn.eduke32.com/eduke32@5180 1a8010ca-5511-0410-912e-c29ae57300e0
I have commented out the versions of these functions that perform bitmasks and shifts and replaced them with versions that cast to and from integral types, pending performance and compatibility research across platforms.
git-svn-id: https://svn.eduke32.com/eduke32@5174 1a8010ca-5511-0410-912e-c29ae57300e0
TODO: Review the value of the continued use of special cases of these swap functions, including the OS-based variants for BSD and OS X, and this assembly.
git-svn-id: https://svn.eduke32.com/eduke32@5173 1a8010ca-5511-0410-912e-c29ae57300e0
This was formerly "fix multi-tile ceiling skies.", but TX beat me to it
and Git automatically figured out how to merge while keeping a linear
history. (Our fixes were identical.) Nice!
git-svn-id: https://svn.eduke32.com/eduke32@5157 1a8010ca-5511-0410-912e-c29ae57300e0
0 - Multiply
64 - Screen
128 - Overlay
192 - Hard Light
Note: These will likely look terrible when combined with the Colorize flag, because of the nature of the Colorize flag.
git-svn-id: https://svn.eduke32.com/eduke32@5146 1a8010ca-5511-0410-912e-c29ae57300e0
Examples: (assuming stock Duke palswaps)
copytile 10000 { tile 0 } // tile #10000 is now the same as #0
copytile 10001 { tile 1 pal 8 } // tile #10001 is now #1 with a full-green tint
copytile 0 { pal 1 pal 23 } // tile #0 now has a full-yellow tint
git-svn-id: https://svn.eduke32.com/eduke32@5139 1a8010ca-5511-0410-912e-c29ae57300e0
-faketilesiz[MAXTILES] removed in favor of simple faketile[(MAXTILES+7)>>3] bitfield
-h_xsize/h_ysize (tile size overrides from .def) are now uint16_t instead of int32_t
-hudmem[2][MAXTILES] removed in favor of adding a hudmem ptr to mdmodel_t
-tilefromtexture performance improvements
-more tsectortype/twalltype usage in various engine functions that read but never write
-continued Polymost cleanups and refactors. Please report any odd rendering errors.
git-svn-id: https://svn.eduke32.com/eduke32@5079 1a8010ca-5511-0410-912e-c29ae57300e0
-lots of stylistic rewrites
-further improvements to anti-fighting code for wall and floor sprites (introduces three new cvars, r_wspr_offset, r_wspr_offset_variance, and r_fspr_offset)
-fixed brief HOM when traversing through a one-way masked wall
-seldomly used "alphahack" feature for hightile textures now represents alpha cutoff internally as a single byte instead of a float
-fixes a handful of issues where geometry failed to draw at certain coordinates from certain angles in certain resolutions
-renames a couple of cvars
git-svn-id: https://svn.eduke32.com/eduke32@5075 1a8010ca-5511-0410-912e-c29ae57300e0
The latter means that running perpendicular thin sector is handled better
if there are e.g. TROR sectors in the same x/y space.
git-svn-id: https://svn.eduke32.com/eduke32@5024 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes engine-side sprite animation in the following scenario: CON code
wants to draw a scene from EVENT_DISPLAYREST, but since it covers the whole
screen, disables the drawing of the 3D scene beforehand (RETURN set to 1 from
EVENT_DISPLAYROOMS). DONT_BUILD.
git-svn-id: https://svn.eduke32.com/eduke32@5020 1a8010ca-5511-0410-912e-c29ae57300e0
- In drawvox(), make view-relative x and y high-precision on desktops. To a
large extent (but not completely), this fixes "stray" fake floor shadow
sprites for voxels.
- In the mouse picking code for voxels, fix a possible integer overflow.
A new engine.c-private function mulscale_triple30() is added.
DONT_BUILD.
git-svn-id: https://svn.eduke32.com/eduke32@5017 1a8010ca-5511-0410-912e-c29ae57300e0
Also, in premap.c:G_CacheMapData(), comment out what was supposedly
intended as a debugging message ("percentage ...").
git-svn-id: https://svn.eduke32.com/eduke32@5009 1a8010ca-5511-0410-912e-c29ae57300e0
cutscene "somefile.anm" { delay 10 } // defines somefile.anm with a delay of 10 120Hz tics between frames. a more typical framerate method may come later, but this is how the originals worked.
Once defined, they can be played through CON with the new playback command, also called "cutscene". It works like this:
definequote 12345 somefile.anm
define ANIM_SOMEFILE 12345
...
cutscene ANIM_SOMEFILE // halts game execution and immediately plays cutscene, resuming execution when finished
...
Sounds can be played during animations (and tiles can be overlaid, etc) like this:
onevent EVENT_CUTSCENE
ifcutscene ANIM_SOMEFILE
{
ifvare RETURN 12 // frame 12
sound FLY_BY
rotatesprite ...
}
endevent
The value of the RETURN var at the end of EVENT_CUTSCENE determines the next frame to play. This can be used for looping, etc. Attempting to play animations backwards outright is not advised as animations only seek in one direction (so rewinding requires running it through from frame 0 again). This is will WIP and hasn't been heavily tested at all, so please try it out.
git-svn-id: https://svn.eduke32.com/eduke32@4987 1a8010ca-5511-0410-912e-c29ae57300e0
And preventing enormous corruption due to a free() called on a garbage (malloc'd)
pointer values this time. DO_BUILD_VERY_FAST_PLEASE!
git-svn-id: https://svn.eduke32.com/eduke32@4980 1a8010ca-5511-0410-912e-c29ae57300e0
Since TILE_TILT is only allocated once, it must be done with the maximum
possible size.
git-svn-id: https://svn.eduke32.com/eduke32@4965 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes the out-of-bounds read of former g_player[] in VM_EventCommon_().
git-svn-id: https://svn.eduke32.com/eduke32@4961 1a8010ca-5511-0410-912e-c29ae57300e0
This prevents a enormous leak being reported by LeakSanitizer. Not that it
matters much, since we most frequently free models only at exit. (Sometimes one
may be freed earlier though -- if there was an error loading it, AFAICS.)
git-svn-id: https://svn.eduke32.com/eduke32@4952 1a8010ca-5511-0410-912e-c29ae57300e0
This makes sure that the engine arrays have sufficient space allocated for usage
in Mapster32's 2D mode, for example from drawmapview().
git-svn-id: https://svn.eduke32.com/eduke32@4938 1a8010ca-5511-0410-912e-c29ae57300e0
- t{sector,wall}type are simply typedef'd to the non-t versions
- make FORCE_INLINE unconditional of DISABLE_INLINING (otherwise there are
multiple definitions of these functions)
- update lunatic/doc/lpeg-lunatic.patch to apply against the LPeg 0.12 I just
downloaded
git-svn-id: https://svn.eduke32.com/eduke32@4937 1a8010ca-5511-0410-912e-c29ae57300e0
In setview(), we now assert windowx2 < xdim. The only calling places where its
non-violation is non-trivial to ascertain are (1) showview from CON and
(2) draw-to-tile for look-sideways in game.c. AFAICS case 1 should be fine.
Case 2 is adapted; see comments there.
git-svn-id: https://svn.eduke32.com/eduke32@4935 1a8010ca-5511-0410-912e-c29ae57300e0
replacements for the first handful of palette lookups) w8th superior
"luma" method. DONT_BUILD.
git-svn-id: https://svn.eduke32.com/eduke32@4889 1a8010ca-5511-0410-912e-c29ae57300e0
This should prevent Lunar Apocalypse from becoming Nuclear Winter with Megaton on Linux and Mac.
git-svn-id: https://svn.eduke32.com/eduke32@4886 1a8010ca-5511-0410-912e-c29ae57300e0
By setting DISTRECIPSIZ to 131072, as far as I can see the absolute maximum
that's possible with the integer scaling convention of the voxel drawing code.
BUILD_LUNATIC.
git-svn-id: https://svn.eduke32.com/eduke32@4881 1a8010ca-5511-0410-912e-c29ae57300e0
- Work around a sequencing issue (assignment of searchstat) in
M32_DrawRoomsAndMasks()
- When having sprites highlighted and changing shade, since r1943 change
every highlighted sprite's shade if one of them is aimed at. With this
revision, if SHIFT is pressed while doing that, only change the aimed at
sprite's shade
- a.m32: Use 'break' from a state instead of 'return'. The former may be
"sticky" in a way that is not intended. Needs to be debugged later.
- Update instructions in m32script_ex.map
DONT_BUILD.
git-svn-id: https://svn.eduke32.com/eduke32@4880 1a8010ca-5511-0410-912e-c29ae57300e0
Also for polymost_scansector(). These were likely of little consequence
because collection in scansector() is the exception than the rule (see
added comments), and because the redundant drawwalls() would find the
x range done the second and following times.
Also, add a bound check for sectorborder[] (the limit was probably rarely
hit in practice, but the check is mandatory nontheless) and add functions
printscans() and printbunches() in the DEBUGGINGAIDS=2 build.
git-svn-id: https://svn.eduke32.com/eduke32@4877 1a8010ca-5511-0410-912e-c29ae57300e0
There were various issues with that code.
- It does not seem to be very meaningful to do so.
- It was carried out on the same range as the sprites sorted by z coordinate
(those with equal x/y) just a few lines away, effectively overriding it.
The former is very meaningful, though.
- It led to inconsistencies between editor and game, see
http://forums.duke4.net/topic/775-eduke32-20-and-polymer/page__view__findpost__p__214873
git-svn-id: https://svn.eduke32.com/eduke32@4876 1a8010ca-5511-0410-912e-c29ae57300e0
- factor out calculation of player-relative and screen+clipped-player-relative
coordinates into get_rel_coords() and get_screen_coords(), respectively
- the usual beautification stuff, especially since we're now on C99
git-svn-id: https://svn.eduke32.com/eduke32@4875 1a8010ca-5511-0410-912e-c29ae57300e0
Previously, the C function clipmove() returned negative values when hit a
wall (32768+wallnum) or sprite (49152+spritenum) because internally,
these values were encoded into a *signed* 16-bit integer. This made no
difference to C code using it, since it always proceeded by bit checks,
but was inconsistent with documentation on CON 'clipmove' on the wiki.
The following commands are affected too, since they use the value returned
by clipmove(): 'clipmovenoslide', 'movesprite'. Also, the value of
actor[].movflag ('htmovflag' from CON).
Also, fix 'clipmove*' in LunaCON and add lunatic/test/checknearwall.con
as an example of how to implement a being-close-to-a-wall checker as
requested in
http://forums.duke4.net/topic/7869-determining-closeness-to-a-wall/
git-svn-id: https://svn.eduke32.com/eduke32@4874 1a8010ca-5511-0410-912e-c29ae57300e0
