Fix for teetering on PolyObjects
So... somebody goofed and didn't realise PolyObject sectors could be added to the sector node list for each object (which is referenced by mobj->touching_sectorlist), via their linedefs if they are nearby the player (yes, PolyObject linedefs are special and get to move about the level). As it turns out, this allows even INTANGIBLE PolyObjects to make you teeter in a seemingly inexplicable way.
What is happening is that PolyObject sectors, when they are added to the mentioned lists, are then checked under normal sector teetering conditions - if the player is above the floorheight by 24 FUs, you're officially teetering unless stated otherwise. The actual PolyObject teetering code can't help you here if the conditions are right, especially if they're taller than 24 FU in height.
There are a number of things wrong with the teetering code in general that I'd like to sort eventually, but at least now teetering on PolyObjects is fixed at last ...right? Please check the branch out if you can to check this, obviously.
See merge request !54
Fixes for patch scaling and V_FLIP usage
The following issues are fixed by this branch:
* a patch using both scaling and V_FLIP does not appear in the "correct" place on the screen. Thanks to LJSonic for pointing this out to me on 'fun
* Scaled and/or V_FLIPed patches wrap at the left/right screen edges even though they're not supposed to. V_FLIP patches at these edges may also crop the wrong side of the patch if they're at the right edge.
See merge request !60
Some fixes for portals
Specifically the following things are fixed in this branch:
* a memory leak resulting from not clearing away clipping-related arrays each tic you view a portal
* a very specific crash to do with portals sometimes (unintentionally) using a hack on drawsegs that don't actually belong to them ...which results in a crash if the drawsegs in question have midtextures. I reported it on the MB a year ago, with a test map included there: https://mb.srb2.org/showthread.php?t=38199&page=4#79
* another specific crash to do with mirrored (horizontally flipped) sprites that are scaled, particularly when you cover up the left edge of them via portals at the least. Needs more testing to be absolutely sure this is fixed, and is also reproducable in the test map linked in the post above
May be fine to merge changes into master too, I don't really know exactly
See merge request !42
Camera fix
This fixes the third person camera being silly around intangible PolyObjects, particularly the fact they can affect the camera's floorz and ceilingz even though I see no reason why they should do so.
Also a good reminder that POF_SOLID is the same as POF_CLIPLINES and POF_CLIPPLANES combined, which is probably how this issue came about to begin with. Can't say that with certainty of course.
See merge request !57
P_ClosestPointOnLine changes
P_ClosestPointOnLine can now (optionally) take custom coordinates for two points that you want to make up a "line", instead of just actual linedefs.
Complete syntax for P_ClosestPointOnLine as of this branch:
```lua
-- syntax for a real linedef (which is already in 2.1.14):
P_ClosestPointOnLine(x, y, line)
-- syntax for a fake line with vertexes (x1,y1) and (x2,y2):
P_ClosestPointOnLine(x, y, x1, y1, x2, y2)
```
See merge request !61
Clang cleanup
"taking the absolute value of unsigned type 'unsigned int' has no effect"
using abs() on an unsigned should be nop, replace them with (angle_t)()
Need someone to verify this does not break any game logic
See merge request !63
Ceiling lighting fix
The ceiling lighting linedef special (and anything else that changes ceiling lighting directly for sectors) works in software mode now.
See merge request !62
P_RandomChance is now a macro for something that should happen a
certain percentage of time.
P_SignedRandom was moved to a macro. Nobody cared.
# Conflicts:
# src/p_inter.c
This actually passes most diehard tests, as opposed to the old RNG.
It's also similarly fast.
Internally the PRNG generates a fixed point number from [0,1) now,
which makes P_RandomKey and P_RandomRange much easier to
calculate. P_Random is just a simple shift, as well.
Also, the lack of floating point math in P_RandomKey and
P_RandomRange now is probably for the best.
