"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?)
When I first wrote this, I thought the .h file that contained a function declaration needed to have the same name as the .c file the function was in. Now I know that's not the case, off to p_local.h with you.
Two interesting points of note:
* The touchspecial sector flag seems to actually do its job now.
* Detection of sectors with polyobjects in seems to have done this incorrectly, but this doesn't mess with anything about touching the polies themselves so it seems to really only handle edge cases where the polyobject was too close to the border of another sector (which would've likely made rendering glitches anyways).
* There was a whole swathe of teetering code that was basically never run properly because of this mistake. I did a simple fix at first, but you started teetering whenever you were slightly less than your radius away from a sector's edge, which was completely different and undesirable behaviour. Instead, I cut out the code that was never running, and just left the hacky method in instead since it was more accurate to what we want in general.
Issue was caused by attempting to traverse the sector's thing-touching-list across all the things in the sector (which would inevitably have the same sector as the first node in mobj->touching_sectorlist) instead of traversing the thing's sector-touching-list (which has the same thing but different sector references).
I wonder how many times AJ copypasted this code with absolutely no idea why it wasn't working properly. I'll figure that out tomorrow, maybe set up some compiler macros so this mistake is never made again. For now, I must sleeb.
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
Behaves ALMOST as you'd expect. It gets the z position of the slope at the player coordinates when it comes to the sectorlist check (which is first), though, so there's a few oddities that are amplified with steep slopes:
* If the slope's sloping away from you at a steep angle, you might not be able to step down onto it, but you won't teeter (because it's at a step-down-able height if it extended to directly beneath you)
* If the slope's sloping towards you at a steep angle, you might end up in teetering frames when you're able to step down onto it (because it's NOT at a step-down-able height if it extended to directly beneath you)
HOWEVER, it would be pretty obnoxious to hold back code which is functionally superior in every way otherwise, and it doesn't really seem like there's a good way to get that checked tbph
* If there's items in it set the FOF's floor and ceiling flats to that of the backside sector's ceiling
* Otherwise, set them to that of the backside sector's floor.
Otherwise, the flats do not change.
This allows for SMW style blocks which are much darker when empty then full on all sides.
* Only change texture when stationary or moving down, for additional fidelity to source material. This has zero overhead, and actually might REDUCE lag in some circumstances... my nitpickiness wins again.
* Apply ML_EFFECT1 to it to make it invisible and intangible (removing (FF_SOLID|FF_RENDERALL|FF_CUTLEVEL) from it) from every side except the bottom. Becomes visible and tangible when it's hit once. Might fuck over players in mp, but really our Mario blocks are so high in the air (and we'd need to update Pipe Towers to take advantage anyways) that they're super unlikely to get a kill this way
* Checks for the Brick Block have been switched over to the presence of FF_SHATTERBOTTOM instead of checking for the source linedef's flags every time.
For the object...
* Tag via its angle field
* Number of objects to spawn per tic around it via its z field, if zero then just spawn at center
* Is flipped if given MTF_OBJECTFLIP.
Now there's a linedef type 15!
* Tag is tag of object(s!)
* Object type set via concatenation of frontside textures, MT_PARTICLE is default
* The length of the linedef is the radius the particle is spawned out (zeroed if z field is 0)
* Frontside x offset is speed upwards
* Frontside y offset is number of degrees to turn each tic (zeroed if z field is 0)
* Frontside floor and ceiling heights are the heights in which the particle is bound through some fun mathematics and/or BDSM
Of course, not every story has a happy ending.
* A_ParticleSpawn no longer accepts objects via its var1 because of how specialised it's gotten. Considering it can be set via abuse of actor->cvmem, I don't consider this an issue. Maybe you might disagree.
Also updated any relevant project files that I can think of to include the new files, as well as the makefile of course. Some of the other project files haven't been touched in years so I'll leave those alone ...unless someone objects
Linedef type 4 now works as follows.
* Frontside x offset is dash speed.
* Effect 4 flag doesn't center the player. (same as before)
* Effect 5 flag sends them off in rolling frames. (as a result there is only one speed pad sector type now, not two)
* Frontside upper texture is sound to play on launch, defaults to sfx_spdpad when not given
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
Linedef type 14 (Bustable block parameter)
* Applied to one of the linedefs of any FOF's control sector
* Concatenation of frontside textures is MT_ object type to spawn, defaults to MT_ROCKCRUMBLE1 if not present
* Sound played when being busted is object type's activesound
* Frontside x offset is spacing (in fracunits) of spawned particles, defaults to 32<<FRACBITS
* Frontside y offset is the fuse of spawned particles in tics, defaults to 3*TICRATE, if set to -1 assume infinite lifetime
* Effect 1/Slope Skew flag makes particles fly out
Linedef type 250 (Mario Block):
* No Climb flag turns it into a brick block (busts when hit from the bottom, player hits their head/fist/whatever, no more upwards momentum)
