That is, make interpolation work properly there -- both when 'using' a
VIEWSCREEN and when rendering the scene onto a TILE_VIEWSCR. This makes
a difference only if the camera is in a moving sector.
git-svn-id: https://svn.eduke32.com/eduke32@4847 1a8010ca-5511-0410-912e-c29ae57300e0
- At a given time, at most one viewscreen may display TILE_VIEWSCR, namely
that one which is g_curViewscreen
- sync kinds of distance to compare against VIEWSCREEN_ACTIVE_DISTANCE (was
Manhattan vs. dist(), now both the latter)
- fix resetting to VIEWSCREEN tile when player is greater from it than that
distance. When the player is closer to it again, it is *not* reset to
TILE_VIEWSCR.
- more sync'd g_curViewscreen and sprite[i].yvel (for 'i' being the viewscreen
sprite)
Note: in a multiplayer context, this needs to be thought about once more.
git-svn-id: https://svn.eduke32.com/eduke32@4843 1a8010ca-5511-0410-912e-c29ae57300e0
The only semantic change is that an out-of-sync instance of a distance to
check (viewscreen sprite <-> player sprite) is changed in
actors.c:G_MoveStandables(), from 2048 (as in Duke3D 1.5) to 8192, now
represented by the define VIEWSCREEN_ACTIVE_DISTANCE. I have not yet observed
any change in behavior regarding this change (but there ought to be one).
Also, in DNCOORDS display, print 'totalclock' count, too.
git-svn-id: https://svn.eduke32.com/eduke32@4831 1a8010ca-5511-0410-912e-c29ae57300e0
VM_OnEvent() has become VM_OnEvent(), VM_OnEventWithReturn(), VM_OnEventWithDist(), and VM_OnEventWithBoth() (the latter of which is only ever used once...). Of course, this required every call to VM_OnEvent() be changed.
memberlabel_t and vmstate_t have been changed to use the regular "int" type versus explicitly specifying int32_t as they did previously. The rationale for this change is simply that it looks cleaner, and I think we should move toward just using "int" in most cases where there's no particular reason to specify an explicit data type.
Also changes CON_KILLIT to just "return" instead of "continue". DONT_BUILD.
git-svn-id: https://svn.eduke32.com/eduke32@4745 1a8010ca-5511-0410-912e-c29ae57300e0
This makes the subway sound not played once on map initialization.
git-svn-id: https://svn.eduke32.com/eduke32@4481 1a8010ca-5511-0410-912e-c29ae57300e0
This flag is set from C for some enemies that should not be pushed back when
damaged, such as TANK. Both the tile flag and the per-sprite flag are used
(i.e. the ultimate flag value is the XOR of the two).
Add currently non-functional example to test.lua that attempts to set this bit
for NEWBEAST.
git-svn-id: https://svn.eduke32.com/eduke32@4371 1a8010ca-5511-0410-912e-c29ae57300e0
- use SPRITES_OF* iterator macros
- new function: E_SpriteIsValid(); add some safety checks
(e.g. hitag used as sprite index)
- the rest is mostly "the usual code transformations"
git-svn-id: https://svn.eduke32.com/eduke32@4281 1a8010ca-5511-0410-912e-c29ae57300e0
It is unacceptable that yvel is on one hand modifiable without restriction from
scripting, but can be used as an array index without prior bound check in the C
code. Because that member has an overloaded meaning and is also used for
innocuous purposes such as the green color intensity of an SE light, it's
infeasible to restrict access from scripting. Consequently, we must add bound
checks on the C side. This is the first part of the effort to make .yvel safe,
adding two functions P_Get() and P_GetP(). There are a couple of other uses as
some kind of index.
git-svn-id: https://svn.eduke32.com/eduke32@4226 1a8010ca-5511-0410-912e-c29ae57300e0
- in the function itself: for floor, currently, do nothing (but this commit
is in preparation of the next one, again)
- In Proj_MaybeDamageCF(), Proj_MaybeDamageCF2() and the A_RadiusDamage() use
if the function, generalize to floors, but with the special case that
parallaxed floors keep blocking projectiles, as before (in constrast to
parallaxed ceilings). However, Sect_DamageCeilingOrFloor() is only
called for non-parallaxed ceilings *and* floors.
git-svn-id: https://svn.eduke32.com/eduke32@4205 1a8010ca-5511-0410-912e-c29ae57300e0
- Move ARRAY_SIZE() macro to compat.h, add another one ARRAY_SSIZE()
- In A_RadiusDamage(): note maybe-unaligned access issue, prevent unlikely oob
- sector.c: use SPRITES_OF* macros where appropriate
git-svn-id: https://svn.eduke32.com/eduke32@4199 1a8010ca-5511-0410-912e-c29ae57300e0
In particular, (int32_t)j != -1 is replaced by (uint32_t)j < MAX_WEAPONS
to prevent a value >= MAX_WEAPONS to be assigned to p->wantweaponfire (it's
used as a weapon index in P_CheckWeapon().
git-svn-id: https://svn.eduke32.com/eduke32@4181 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 S_PlaySound(), move the sound index bound check above an indexing.
- For A_CheckHitSprite(), and A_FindPlayer(), allow NULL second arg.
- In A_ShootWithZvel(), make some one-letter vars be int32_t, making
storing safeldist() results in them meaningful.
- In MaybeTrainKillEnemies(), remove two redundant checks and move another
one further up.
- Comment that SIDEBOLT1 will never be translucent as was probably intended.
- In G_MoveFX(), fix an always-true comparison.
git-svn-id: https://svn.eduke32.com/eduke32@3680 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
This is done by always calling FX_PlayAuto3D() to play such sounds. It now
additionally takes a third argument 'loophow', permissible values being
FX_ONESHOT and FX_LOOP.
git-svn-id: https://svn.eduke32.com/eduke32@3631 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
The redundant ones are in code like this: s->cstat = (int16_t)32768;
Because the value is eventually converted to the type of "s->cstat", any
casts to integral types having at least as many bits are no-ops, signedness
being irrelevant due to (probably any two's complement arch targeting
compiler's) bit-pattern preserving semantics of these conversions.
The now incorrect one is: if (lotag == (int16_t) 65535),
"int32_t lotag" being read from a wall or sprite struct directly earlier.
Now, with these members being unsigned, and (int16_t)65535 equalling -1,
the check always fails. The correction fixes normal switches having such
a lotag ending the level immediately.
In short: integer casts before assignments are unnecessary, those in reads
highly relevant!
git-svn-id: https://svn.eduke32.com/eduke32@3211 1a8010ca-5511-0410-912e-c29ae57300e0
This reverts r3159..r3161.
Conflicts:
eduke32/build/include/compat.h
(Handled so that r3163's changes are kept applied.)
git-svn-id: https://svn.eduke32.com/eduke32@3165 1a8010ca-5511-0410-912e-c29ae57300e0
I think there's also a fix for the CON precache system breakage in here (lost it in my local tree when I started getting the C++ build working in MSVC, sorry!)
git-svn-id: https://svn.eduke32.com/eduke32@3159 1a8010ca-5511-0410-912e-c29ae57300e0
