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
This may happen if no title/end music is defined from CON.
Thanks to Zaxtor for the bug report.
git-svn-id: https://svn.eduke32.com/eduke32@4871 1a8010ca-5511-0410-912e-c29ae57300e0
In A_RadiusDamage(). The code snippet that is disabled for such actors
increases the damaged actor's .xvel by (4 times the) damage amount and
is responsible for the strange effect of enemies becoming faster TOWARDS
the player on being hit with an RPG frontally.
Thanks to Fox for a keen eye.
git-svn-id: https://svn.eduke32.com/eduke32@4863 1a8010ca-5511-0410-912e-c29ae57300e0
