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.
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.
This isn't necessary. When rendering no actors from other groups may ever come into view directly - only when the respective part of the level is rendered through a portal. But at that point the camera is in a position where it's already correctly placed with relation to that actor.
The only reason this even existed was that ZDoom's original VC projects used __fastcall. The CMake generated project do not, they stick to __cdecl.
Since no performance gain can be seen by using __fastcall the best course of action is to just remove all traces of it from the source and forget that it ever existed.
Added temporary solution for the same foreground and background colors of the title in OS X startup window
It's used in graphical startup screen, with Hexen style in particular (for example WolfenDoom - Blade of Agony)
Native OS X backend doesn't implement this yet
Due to the VC++ 2015 headers being rather bloated (the average include size per source is 400-500kb) this provides a noticable compile speedup, although right now this only covers the game code, so there should be more room for improvement.
This means that the varargs functions themselves are now responsible for parsing them into DrawParms.
This was done because DrawTextV made a blanket assumption that every single vararg has the size of a 32 bit integer and caused crashes when anything else was passed. It also failed to eliminate any tag that is incompatible with text display. These will now abort DrawText and trigger an assert.
In order to avoid passing around tag lists, DrawTextV needs to parse everything itself and then pass a fully initialized structure to DrawTexture. This cannot be done if all variants require a varargs tag list.
Apparently the only reason for the old approach was the 'hw' parameter which was never used.
What was the point of this strange setup anyway? MoveFloor and MoveCeiling were inlines calling the universal MovePlane, which had nothing better to do than a switch/case with two cases - floor and ceiling!
Normally this will adjust relative to the actual direction to the target, but with arbitrary portals that cannot be calculated so using the actual attack angle is the only option.
Sadly the mappers cannot be trusted to use a feature correctly. Despite repeatedly telling that portals on one-sided lines are problematic, everybody seems to do it this way - and then report bugs if it doesn't work. Under such circumstances the only safe option is to block such portals entirely.
See http://forum.zdoom.org/viewtopic.php?f=2&t=51511&p=898522#p898522 for a typical example of the problems this might cause.
This code was ported from the 2005 floating point version, at one point it replaced 128 with 0.5, but 128 as a fixed point value needs to be 1/512. as a floating point value.
This will fail when a trace starts directly on a block boundary in which case x is a whole number. It should always use 'floor(x)+1' to ensure that the calculated point is at the right or upper edge of a block.
* we do not really need compatibility PointOnLineSide here. Unlike the movement code it'd only affect some extreme edge cases.
* removed the special case for very short traces. This was a result of the original and very imprecise PointOnLine functions. Since those no longer get used here and floating point precision is a lot higher there is no need for this kind of treatment.
* PointOnLine checks for the sides of an actor's bounding box don't need a full PointOnLineSide call, a simple coordinate comparison is fully sufficient, and this can easily be done in the existing switch/case block.
