This was to resolve some circular dependencies with the portal code.
The most notable changees:
* FTextureID was moved from textures.h to doomtype.h because it is frequently needed in files that don't want to do anything with actual textures.
* split off the parts from p_maputl into a separate header.
* consolidated all blockmap related data into p_blockmap.h
* split off the polyobject parts into po_man.h
* the sight checking code needs to be as precise as possible and should not depend on some old semi-broken routines. (This is more a precision issue of these routines - P_PointOnDivlineSide removes the lower 8 bits of each value - than having an issue with returning the wrong side in some cases.)
* for slope creations it is flat out wrong to use the old routines at all.
* also ignore this in the modern (box-shaped) case of FPathTraverse::AddLineIntercepts. This functionality is new to ZDoom and therefore not subject to compatibility concerns.
* the line-to-line teleporter. It seems the hideous fudging code was just there to work around the design issues of these functions, so let's better not ever call them here in the first place.
* A_PainShootSkull: Its usage here does not depend on these issues.
* P_ExplodeMissile: New code exclusive to ZDoom.
* FPolyObj::CheckMobjBlocking
All occurences in p_map.cpp have been left alone although most of them probably won't need the compatibility option either.
The old method had a problem with missing order numbers and aborted the level load and made many assumptions that no longer apply with BSP based polyobject rendering.
This happened when the polydoor was open. If a mobj blocked the poly door, such that the door could not move from its open position, the poly door could rotate a little bit more than needed, making the door partially closing when the door managed to close later.
continue spinning until the next time around because the check for moving too fast was only
done after the polyobject had been rotated once.
- Reduced the potential for overflow when setting up the speed of a rotating polyobj.
SVN r4332 (trunk)
can perform based on the amount of damage actually taken after all modifications are done to
it. However, if the damage is canceled away, blood will still spawn for the original damage
amount rather than the modified amount.
SVN r4012 (trunk)
alters the opening. This fixes things such as removing a projectile when it hits a 3D midtex
instead of exploding it because the real floor or ceiling is sky.
SVN r3490 (trunk)
- fixed: APROP_Invulnerable could only be set and unset but not checked.
- fixed: Two sided polyobjects applied thrust to sctors in a way that did not work.
SVN r2620 (trunk)
- added Polyobj_MoveToSpot action specials. They are functionally identical to Polyobj_MoveTo but get the target coordinate from a map spot instead.
SVN r2503 (trunk)
SoundSequenceOnActor(int tid, string seqname);
SoundSequenceOnSector(int tag, string seqname, int location);
SoundSequenceOnPolyobj(int polynum, string seqname);
SoundSequenceOnSector takes an extra parameter that specifies where in the
sector the sound comes from (floor, ceiling, interior, or all of it). See
the SECSEQ defines in zdefs.acs.
SVN r1939 (trunk)
velocity, and now it's known as such. The actor variables momx/momy/momz
are now known as velx/vely/velz, and the ACS functions GetActorMomX/Y/Z
are now known as GetActorVelX/Y/Z. For compatibility, momx/momy/momz will
continue to work as aliases from DECORATE. The ACS functions, however,
require you to use the new name, since they never saw an official release
yet.
SVN r1689 (trunk)
sounds are handled.
- Why do polyobjects have a 3D start spot? Flattened it to 2D.
- Moved the sector sound origin calculation out of fmodsound.cpp and into
s_sound.cpp so that the near sound limiting will use the correct sound
location for deciding on neighbors.
SVN r1061 (trunk)
might still be present in the texture manager; I don't remember.)
- Fixed: EndSequence needs a proper constructor.
- Some more GCC warning removals.
SVN r1021 (trunk)
