Optimisation of P_GetMobjGravity (relevant for slopes)

Cleaned up some performance issues in Skytop Zone (2.1.16: THE SUGOI UPDATE) arising from some inefficiencies with P_GetMobjGravity. FPS drops only occasionally to 34 now, which is a big improvement when I was frequently getting 27 in Salt's 15andahalf.exe.

(I also tested in a build of 2.1.16's first release candidate, and was getting drops to 16! So SOMETHING improved since then, but this was the major issue.)

See merge request !109

Cleaned up some performance issues in Skytop Zone (2.1.16: THE SUGOI UPDATE) arising from some inefficiencies with P_GetMobjGravity. FPS drops only occasionally to 34 now, which is a big improvement when I was frequently getting 27 in Salt's 15andahalf.exe.

Climbing shit 2 electric boogaloo: an adventure in how much toast hates how the ogl renderer was implemented

Fixed Knuckles being able to climb in space in OpenGL.

Using the last-touched line instead of R_IsPointInSubsector because FLOAT_TO_FIXED is bad in P_ functions

To understand the original problem: look at AjustSegs(void) in hw_bsp.c. It reallocates the vetex_t pointers for lines as POLYVERTEX_T pointers, and of COURSE things are gonna get wacky when you're casting pointers.

This merge request is into master because it's a bug that's IN master and must never reach the public because of how bad it is

See merge request !101

Solved the climbing-on-one-sided-lines problem another way, using the last touched line's attributes.

(After talking to Alam, we can't have floats anywhere near P_ functions, so.)

To understand: look at AjustSegs(void) in hw_bsp.c. It reallocates the vetex_t pointers for lines as POLYVERTEX_T pointers, and of COURSE things are gonna get wacky when you're casting pointers.

I dunno how resilient the FLOAT_TO_FIXED solution is or whether it'll be netgame compatible (yayyy float precision loss) but it's not like our builds are netgame compatible with themselves

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

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

Take out fixedheight-based hacks for checking if floor or ceiling! Use an "isceiling" boolean for that instead

This apparently fixes most of the issues with ceiling slopes in Boinciel's SUGOI map

If you want more specifics, sloped FOFs are to blame it turns out: sometimes the bottom of an FOF wall blocking a segment of an in-level wall column can be considered ABOVE the top part of the FOF there (yikes), and then the dc_y* values go offscreen, and then BOOM

Software crashes fix... fix

Fixes a typo introduced by merge request !75 that caused upper textures to set the wrong ceiling clipping value when not visible, allowing all sorts behind the walls to be visible. This is most noticable in GFZ2 when the inside of the tunnel section is visible

...probably a good idea to make sure this one doesn't introduce any MORE visual glitches by mistake (again, compare with 2.1.15 if possible)

See merge request !93

Fix for flats with transparent pixels on slopes

This fixes how R_DrawTiltedSplat_8 unintentionally allows the cyan pixels to NOT be considered "transparent" if after being remapped, depending on sector brightness and/or linedef type 606 colormaps, the result of remapping is not palette index 247 (the cyan we typically turn transparent). That is, the original colors from the source flat graphic are not checked, but instead the __result__ of coloring the flat under the respective colormap is checked for "transparent" pixels. This is only a problem for the tilted splat drawing function, not the regular one for non-sloped planes with cyan-pixel-using flats.

I found out about this bug from the issues Ritz was having with sloped 255-alpha translucent FOFs using transparent flats and his custom COLORMAP lump (and later when he applied a linedef type 606 colormap to the FOF) for his custom map. Thankfully he has some workarounds, but this should fix the code-side issues that caused his problems in the first place.

I also fixed stuff with another splat drawing function that's not currently used atm (maybe it will be in the future, if splats themselves are ever enabled again? *shrugs*).

See merge request !92

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

Gas jets, fan objects, springs and slopes

Whoop whoop whoop minor bugs that only get noticed due to weird experiments whoop whoop whoop

* For gas jets only: the object's standingslope is ALWAYS null. No drifting down the slope for you.
* For gas jets and fan objects: Now checks whether the player's top is below the bottom of the launcher, instead of its bottom. zdist calculation not affected, since it's signed and okay with being negative by about the height of the player.
* For all 3: the player's standingslope is NULL'd so the player isn't launched off at a wacky angle if they're standing on a slope then walk into the thing.

See merge request !91

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

Re-factoring AA tree code from m_misc.c/m_misc.h into its own files

What the title says. The AA tree-related code now lives in the files m_aatree.c and m_aatree.h. Part of why I did this was to solve this m_misc.h/w_wad.h cyclic dependency problem (involving MAX_WADPATH and AA trees themselves) mentioned in the now-removed comments, another reason was ...only OpenGL uses AA trees at all, why include the relevent structs/functions/otherwise anywhere except where is necessary (which is very few files as it turns out)?

Otherwise, it just looked better on its own rather than mixed with all the other stuff already in the m_misc files. Not really important or anything affecting gameplay at all I guess.

See merge request !82

Slightly unrelated, but if R_DrawTranslucentSplat_8 is ever going to be used this is probably more efficient (also fixing early colormap application for the last part)

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

- Now checks whether the player's top is below the bottom of the fan/gas jet, instead of its bottom. zdist calculation not affected.
- mo->standingslope is NULL'd so the player isn't launched off at a wacky angle. (I also did this for springs, since Prime mentioned it was a problem for them too.)