This isn't used for the 3 action function calls because it requires an array allocation which would be a bit too costly for something as frequently called as action functions.
They will need a different approach.
This allows retaining the functionality, even if for the JIT compiler's benefit all default arguments are pushed onto the stack instead of reading them from the defaults array.
There were some issues here:
* a check for mismatching count is too strict because it is legal to omit return values
* it failed to detect returning multiple values in a single expression.
This can happen if a state that's retrieved with FindState gets used with a different actor type and can lead to hard to trace problems if not checked.
This will now both exclude floor caps when only ceiling elements are used and everything outside the bounding box of active portal lines.
Hopefully this is enough to fix the issues with portal caps but of course it is not foolproof if someone just makes the right setup.
The main reason is to unify the portal hierarchy again. The split into a hardware independent and a hardware dependent part turned out to be unnecessary and complicated matters.
Another issue was that the new stencil setup code was having a few subtle problems, so this recreates the original ones with indirect API calls.
- Works similarly to CanCollideWith.
- Passive means the caller is trying to be resurrected by 'other'.
- Non-passive means the caller is trying to resurrect 'other'.
* Colors can npw be defined per sidedef, not only per sector.
* Gradients can be selectively disabled or vertically flipped per wall tier.
* Gradients can be clamped to their respective tier, i.e top and bottom of the tier, not the front sector defines where it starts.
The per-wall colors are implemented for hardware and softpoly renderer only, but not for the classic software renderer, because its code is far too scattered to do this efficiently.
Apparently they can indeed happen with broken map setups like isolated linedefs somewhere in the wild (see Strife MAP08.)
Although they are a problem for triangulation, this isn't what sections get used for currently so it's of no real concern.
In case this is needed later their work data gets marked as 'bad' for the time being.
