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

Sorted an issue MI discovered (I was basing the flip code off the C0 scenario rather than the Cn one)

Merge branch 'master' of http://git.magicalgirl.moe/STJr/SRB2Internal.git into new_new_spriteframe_angle

-warp checking for invalid map names

I've noticed a bunch of new people getting the "Cannot warp to map 0 (out of range)" error when testing their custom maps. On asking what map name they used, it was clear they didn't use a MAPxx name at all. Sadly it was not obvious to them that other kind of map names are not accepted by SRB2, so I thought it best we make that more clear in-game.

SRB2 now gives you the error "Cannot warp to map \[your input\] (invalid map name)" if you used -warp with a param that is neither a MAPxx name or a plain number.

See merge request !99

P_FindSpecialLineFromTag crash fix

This fixes the case where an in-level sector or FOF control sector with a tag of -1 or 65535 (seriously, who does that?) can possibly lead to a crash in this function when searching for heat linedef specials in 1st person. And also the same kind of crash any other sort of weird case where the tag number that function uses for searching is -1 or 65535, I suppose!

See merge request !98

Fix R_AddSingleSpriteDef's I_Error messages

Whoops, seems I forgot about this little branch. Basically this fixes how for a character's sprites, a full sprite lump name is displayed instead of just its sprite prefix in the "R_AddSingleSpriteDef: No patches found for [sprite prefix] frame [frame character]" message (unlike when it occurs for non-character sprites), resulting in something like "R_AddSingleSpriteDef: No patches found for PLAYC2C8 frame \^" which does NOT help custom character authors at all as it just confuses them instead. (for the record, the problem would actually with the ^ frame and not the ones displayed after "PLAY")

Oh, and the same problem is also fixed for this similar message: "R_AddSingleSpriteDef: Sprite [sprite prefix] frame [frame character] is missing rotations"

See merge request !95

Merge branch 'master' of http://git.magicalgirl.moe/STJr/SRB2Internal.git into new_new_spriteframe_angle

Spr2 freeslots

Needed for Miles, generally a good idea to have around anyway. Considering Miles uses it without problems, seems to work fine.

See merge request !24

Detect if -warp's parm is actually a valid map name (MAPxx or plain number), and print an "invalid map name" message if not