Skybox rendering offset fix for third person/alt view camera

Fixes the issue reported in this thread: https://mb.srb2.org/showthread.php?t=41729

I dunno if this will negatively affect any existing skyboxes in SRB2's own levels, that said. I tried out THZ2 and CEZ1 with this fix at least but I forgot to compare them with how they are in 2.1.15 so _*shrugs_*

See merge request !94

OS X Makefile build setup

This merge request:

* Cleans up the OS X bundle resource location code and fixes a SIGSEGV and memory leak
* Simplifies and fixes the OS X desktop alert code, closing more leaks
* Adds the MACOSX build flag to the Makefiles, to allow building a binary (but not Mac app yet) of SRB2.

This is intended to make it easier for developers to build on Mac OS X, without having to pull in all of XCode. You can keep using CMake if you prefer.

To test, use `make -C src MACOSX=1 NONX86=1 SDL=1 NOASM=1` for a release build.

Left to do:

* Add a content bundling script to be run after building, and a flag to trigger doing that.
  `MACOSX_BUNDLE` maybe?
* Somehow get access to a Mac running PowerPC and figure out how to build a multi-platform binary.
* Add the proper magic to compile using gcc if requested. (Right now, compilation is done via LLVM/Clang)

See merge request !72

This reverts commit 8607f524, reversing
changes made to 11d76a65.

Remove i_net.c

The code in i_net.c doesn't actually seem to be used in SRB2. I was able to compile a build without it, and hosting and joining netgames worked just fine (well, as fine as they can with the current state of the netcode...).

The vast majority of code in the file seems to be contained in HAVE_SDLNET ifdefs, and I'm pretty sure SRB2 has never used SDLNET in a public build. The only bit not contained in that block is I_InitNetwork(), which just prints an error and returns false.

Do we really need to keep it around? If not, I say get rid of it. It seems like useless clutter that is just going to confuse people who are trying to understand the source code.

See merge request !73

For GCC 6.1 builds

I do not know what I was doing:

NULL checks

building without BLUA support

functions that do not depend on outside vars should be tagged with "const", AKA, FUNCMATH

See merge request !89

Some other software fixes/changes

Some other software fixes/changes I've made

* Change 1: single-sided linedef midtextures (read: not double-sided linedefs, but single-sided) now don't skew if Effect 2 is checked. Before, there wasn't any ability for software to disable skewing for them. =V
* Change 2: PolyObject back side midtextures now return to being where they should be. Had to make a hack to fix this though.

See merge request !86

Software crashes fix

This branch SHOULD fix the many crashes people have reported lately that all point to the software renderer. Simply put, the software renderer allowed stuff to be drawn out of the screen even though that wasn't safe, and even the existing checks to prevent that didn't work.

If you saw me worrying about the sky HOMs I discovered in AGZ earlier in the commits for this branch, don't worry - it turns out that issue already existed in 2.1.15's srb2win.exe (and probably srb2dd.exe too) anyway, the changes in this branch didn't cause them. Hopefully nothing else broke then.

See merge request !75

Effect 2 (No Midtexture Skew) now toggles off skewing for midtextures on single-sided lines, which was what was intended for them to begin with apparently.

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?)

Fix for rendering sprites in skyboxes

This branch fixes the visual glitches one sees with sprites for objects within skyboxes, typically with parts of or all of some sprites disappearing from view even though they shouldn't be.

See merge request !84

OpenGL slope fixes again

This branch just adds the relevant code for OpenGL to properly check slopes regarding "closed door" segs (those between two sectors that cannot be crossed normally) and "window" segs (those between two sectors of differing plane heights that you CAN cross, which would probably display top or bottom textures), so you don't get HOMs when the the slopes create a closed door even though the normal sector heights wouldn't or something.

(if you couldn't understand that, my slopes test map shows what I mean to the right of the player start: https://dl.dropboxusercontent.com/u/25409000/2.1/mi-slopetest.wad)

See merge request !81

OpenGL: Fix lower unpegged texture offset, fix lower unpegged + effect 1 so the texture actually skews