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.
