Two issues:
Portal linking requires all skyboxes in the sectors to be present, without them some info is not there when needed.
UpdateWaterLevel was called in AActor::Serialize, which operated on the freshly loaded level where lots of things haven't been set up yet and plane heights may be wrong.
All the PortalBlocks* functions were turned into real function calls which for such a frequent check should be avoided. So now any linked portal sets a flag in the attached sectors so that it isn't necessary to check the skybox pointer each time which makes the functions subject to inlining again.
- When the camera texture for a player view was rendered, its psprites
would overwrite the ones stored for hardware acceleration.
* Use a temporary vissprite in R_DrawPSprite() until it's known that it
will be accelerated.
* Do not write to any of the VisPSprites*[] arrays until it's known that
the sprite will be accelerated.
This got accidentally committed. Even if this gets extended to reach through portals it needs to be done differently. FMultiBlockLinesIterator can't guarantee to get every sector that's being touched.
This is for rendering the sprite properly in all areas the actor touches. The original thinglist is not sufficient for this and Boom's touching thinglist has other purposes and collects too much data.
This new list will only get filled in when the actor is actually crossing a portal plane, for the normal sector thinglist will still be used.
This piggybacks on the msecnode_t code which has been extended to be able to handle more than one list by passing the sector's membert pointers as parameters.
This needs to be incremented more locally to the place where it is used, so that it is guaranteed that each viewpoint that needs to be rendered increases it.
As a result the uses in the portal code could be removed.
The old code kept the dead thinker, resulting in constant deletion and recreation of the subsector links and PolyBSP because the interpolation kept running.
Changed it so that the thinker is destroyed and the polyobject gets blocked by setting a new flag.
This required some changes to the Trace function because it turned out that the original was incapable of collecting the required information:
* actors are now also linked into blockmap blocks on both sides if they occupy the boundary of a sector portal.
* Trace will no longer set up parallel traces in all parts connected with sector portal, but only use one trace and relocate that on the actual boundary.
This check is only active for linedef based portals, due to the large amount of maps that did it wrong with thing based portals.
Although it may well be that there are some maps that abuse this omission for linedef portals as well, these are better handled with a compatibility option if the need arises.
The main reason this was added is to streamline and optimize the portal handling between renderers in ZDoom and GZDoom. For that both need to show the same general behavior and for linedef portals it is also important to handle the same as in Eternity.
In some situations it can happen that the sector here is not the frontsector of the anchor linedef, because some colinear node line with opposite direction causes this to be positioned on the wrong side. The only remedy here is to explicitly set the correct sector after spawning these things.
