Multi-patch texture support for transparency AND translucency
Fixes the transparent bits of the multi-patch glass texture in THZ1 turning cyan when linedef types 900-908 are applied for translucency
See merge request !56
*Added FLIPX/FLIPY support for multi-patch textures and single-patch textures without holes
*Added FLIPY support for single-patch textures with holes; I'll sort FLIPX support out later
FOF wall slope skewing
FOF walls now can optionally skew with respect to slopes (software mode only currently):
* Upper Unpegged on the CONTROL linedef enables wall skewing
* Lower Unpegged on the IN-LEVEL linedefs ^1 determine which slope to skew with respect to (off = top slope, on = bottom slope)
* If Transfer Line is used however, Lower Unpegged on the control sector's linedefs does the above's job instead
^1 (this is because they already control pegging of individual FOF walls as it is, so this is for convenience and my sanity that they also deal with skewing)
See merge request !39
Skewing direction is decided per in-level wall by the Lower Unpegged flag on in-level linedefs themselves, since they already decide the stuff for FOF wall pegging as it is. That is unless Transfer Line is involved which moves everything to the control sector linedefs instead...
This means the current skewing-by-default effect isn't changed, and OpenGL's equivalent code doesn't have to be touched since apparently it was already like that.
"frontsector" in this part of the code isn't actually the polyobject's sector for back-side polyobject segs, it's the in-level sector the polyobject as a whole is being rendered in it turns out.
Red apparently left in code for single-sided linedefs to NOT skew their midtextures ...but it doesn't work because it doesn't stop the skewing code from running instead, regardless of whether Effect 1 is on or not. If it's decided single-sided line midtextures shouldn't do this though, the non-skew code could just as well be thrown out lol (or something else I guess?)
the most common condition (correct drawing) shouldn't be last, however it can't be first without making the conditions longer anyway.
it's a nitpicky thing, but this is the renderer we're talking about here.
i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs
Previous overflow fix resulted in extra tall FOFs disappearing up close (see: ERZ1's elevators at start)
This works "better" in that only some lighting bugs and really really finicky visual glitches show now. I give up trying to totally fix this stuff dfsdfgdgf
This appears to fix a few holes that have been known to appear with FOF slopes sometimes, dunno how they actually came about exactly but this apparently sorts them out
The funny thing is you really can't see ANY change here unless you have a sloped FOF intersecting a sector floor/ceiling (and a second FOF on the other side), which has other problems anyway lol
Note: polyobj_t's "translucency" is apparently a SIGNED integer, so in theory it's possible to get polyobj flats to use the "spanfunc = splatfunc" line using negative values. If this is not meant to happen, this should probably be fixed asap
Conflicts:
src/f_wipe.c
Compiling errors fixed in this commit:
* Various cases of mixed declaration and statement code
* Implicit declaration of slope functions (read: you forgot to put "include "p_slopes.h" in MORE than a few places)
* an odd case of a bad fixed_t to float typecase, cause by using P_GetZAt directly inside FIXED_TO_FLOAT
* a few minor cases of bad unsigned-signed comparisons
* no prototypes for some of the new slope functions. For goodness sake Red, this is basic stuff!
