* flips the sprite ala MFE_VERTICALFLIP except you don't need to flip the direction of gravity for the object just to draw upside down
* stacks properly with reverse gravity

Introducing MF2_LINKDRAW! I put it in this branch because it (ab)uses some structural changes I made for papersprites.

* Sets the sortscale of the mobj to that of its tracer.
* Basically, Smiles' tails won't clip through shields thanks to this.
* http://gfycat.com/GraveGlassEwe
* Also has support for chains of MF2_LINKDRAW!

Fixed new new spriteframe angle

@Nev3r helped me discover a crash caused by NAMEcLcR not loading patches into every angle lump slot. This is the smallest possible change that fixes the crash.

This is a one line change exclusively modifying an edge case for a feature which isn't available in public builds. Therefore, it SHOULD require (almost) zero code review, and I would've committed directly to master if I had the ability to do that (and the desire to disregard ettiquette). Please help me out here.

See merge request !38

This is the smallest possible change that fixes the crash.

* Reorganised R_DrawVisSprite to do less needless variable calculation.
* Corrected some clipping oversights.
* Made a few comments clearer.

Sorting is fixed! Turns out rover isn't a FOF, it's another sprite. Thanks @RedEnchilada for noticing this oversight!!

http://gfycat.com/EsteemedPleasedDuck <-- so great

A revert of the sorting because it produced better (but not perfect) results for paper and normal mobj interaction.

Also, I added more sortscale handling in the places where I forgot it.

I probably need some help with the maths here to get this to work nicely. http://gfycat.com/LimpAgedDowitcher

Fixed the between-objects sorting problem previously mentioned in the merge request. Now they're sorted by whichever sprite has an end closest to the camera, instead of the middle point previously used.

http://i.imgur.com/UyOKX5u.png <-- this common glitch with crawlas given MF_PAPER (THEY'RE NOT GOOD AT TURNING NEAR EDGES) used to show the behind-crawlas in front of the front-crawlas.

Unfortunately, I've just discovered this issue (which happens with the old version of the sorting code too): http://i.imgur.com/QNjbATB.png but to be fair these crawlas have gotten stuck inside the edges of this platform, so I'm not sure I can do anything about this without cutting off Sonic's feet when he stands on the ground? shrug

Added linedef collision and fixed the following clipping bug, shown in gfy form. http://gfycat.com/BiodegradableNaturalHadrosaurus

* MF_AMBUSH is now MF2_AMBUSH, because it's something you turn on in a map editor, not with a SOC definition.
* Where MF_AMBUSH was is now MF_PAPER.
* MF_PAPER accesses all the stuff I did previously in this branch...
* ...as well as turn on paper-thin collision detection between mobjs, which I've gotten working but isn't perfect but it's still good enough for non-solid objects!!

* recognising that the offsets weren't going to be accurate if you just SWAPPED yscale and yscale2 over 180 degrees
* taking scale into account consistently

also, some optimisations

http://gfycat.com/SimpleShallowDeviltasmanian

now to put this behind some sort of flag and optimise it

Some overflow checks. They're not proper like the other overflow checks, but they remove all the situations I've been able to discover without making stuff unnecessarily disappear.

Also, discovered another undesirable bug, but don't understand exactly what's going on so won't describe it here.

also, i've sussed out WHAT'S going wrong here - the topleft pixel of the sprite will always be rendered at the height on the screen it would be rendered otherwise, which is causing the waving. now to figure out what to change to get that to move appropriately...

some complicated mathemagic leads to something which... seems CLOSE, but not perfectly accurate, so i think i need to tweak it more

http://gfycat.com/JovialSpitefulAmericancrayfish for current behaviour

remove all the places where i've set vis->scalestep to anything other than 0 to see something that LOOKS okay, but doesn't fulfil exactly what i want (that being a sprite that looks exactly like a midtexture)

NAMEcLcR sprite angle loading, take 2

HEY LOOK, A NEW SPRITE LUMP LOADING FEATURE (which isn't that new since this merge request description is literally copypasted from the one for public next)

 * NAMEcL refers to a frame which is seen for the entirety of an object's left side. (ie - in 2d mode, facing to the left relative to the camera)
 * NAMEcR refers to a name which is seen for the entirety of an object's right side. (ie - in 2d mode, facing to the right relative to the camera)
 * NAMEcLcR does both sides, duh. I didn't break reflection.
 * Having just a NAMEcL requires you to fill in the opposite side either with NAMEcn where n is 1 and 5-8 OR a NAMEcR OR a NAMEc0
 * Having just a NAMEcR requires you to fill in the opposite side either with NAMEcn where n is 1-5 OR a NAMEcL OR a NAMEc0
 * Switches down the centerline of the object instead of at the ANGLE_202h interval for normal sprites. Has a very small window where you can see a NAMEc1 and NAMEc5 if you only use one of NAMEcL or NAMEcR down one side.
 * The specific symbols selected for this were selected for 1) ease of mental understanding (Left, Right) and 2) not getting in the way of adding support for zdoom's totally bananas 16-way sprite system at a later date if we so choose, which only goes up to G

totally makes sense for stuff like NiGHTS stuff, Axis2D stuff, and maybe if SRB1 survives the chopping block in some shape or form it can take advantage of that too

See merge request !33

OpenGL planes fix

This branch removes a specific hack in the OpenGL code for detecting if a plane is for the floor or ceiling of a sector. This it turns out fixes ceiling slopes in Boinciel's SUGOI map going missing. Though, It doesn't fix that other glitch with one FOF (must be unrelated).

If you want to test these fixes out properly, make sure working in-level sectors, FOFs AND also polyobjects all still work fine, sloped or not.

See merge request !97

Fof slope crash fix

This fixes yet another software renderer crash, this time relating to sloped FOFs: sometimes the renderer thinks parts of FOFs where the top and bottom heights are the same height are actually the bottom going through the top (in other words a negative height). This causes problems when drawing normal walls around such FOFs since the game obviously doesn't expect negative heights anywhere along the FOF - before slopes, the game could just flip around the top and bottom heights automatically with no problems. This branch also should fix crashes for all genuine cases of negative FOF heights when slopes are involved, I suppose.

Hopefully this stops FuriousFox's SUGOI map crashing for the time being, all seemed fine when I tested it out myself.

See merge request !96

Please don't assume indentation carries intent, especially since a break that exclusively follows an I_Error will never run