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
* 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
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
I DID make some steps towards re-implementing PIT_CheckThing for solids only in order to replace the hack long-term and hopefully use less CPU, but is currently disabled via #if 0 since I'm not comfortable changing the function signature of P_CheckPosition right now.
If there's any reason to bring the old system back we could make it togglable by one of the linedef flags I suppose. Not that many people would actually use it though, most likely
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)
* Effect 3 (Peg Midtexture) is now accounted for properly, flipping the collision box position to match the actual rendered position of the midtexture
* Fixed incorrect application of y-offsets for non-lower unpegged midtextures collision boxes; +ve always goes up, -ve always goes down!
* Effect 4 now doesn't make midtextures solid for polyobjects at all - this "conflicted" with First Line having both Effect 4 (visible planes) and Effect 3 (intangible) simultaneously, where we kind of expect the first line's wall to not be made solid. This may be less of a problem in future SRB2 versions, but for now solid midtextures for polyobjects are disabled.
. tmthing can be NULL if called from PTR_SlideTraverse, so we should use slidemo instead
This fixes a crash that occurs in yet ANOTHER SUGOI map, involving bouncy walls next to sloped floors/ceilings
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
* The NiGHTS drone had a single tic of visibility when you hit the goal, which is evident stepping frame by frame through http://gfycat.com/ComplicatedComposedAoudad (the contents of which may or may not make it into 2.2).
* When completing a NiGHTS stage with a non-zero link, the link could flash up in the final few tics before the fade to black. This just checks for player->exiting to make sure it shouldn't be shown.
* That hacky anti-NiGHTS-deaxisment code I commented out because I thought it was visual only? Reimplemented in a way that is both more and less hacky. It's identical in result to the original code, but takes a roundabout method to get there.
* Sprite references for SUPE, SUPZ and NDRL are removed because they are now unused.
* Helper's flashing conditional is restructured to do less flag swapping.
* The check for super setting FF_FULLBRIGHT is limited to MAXTRANSLATIONS now, and also correctly takes into account MAXSKINCOLORS == SKINCOLOR_SUPERSILVER1.
* NiGHTS collision bounds aren't hardcoded anymore.
* NiGHTS link will never display when leaving stage.
* Slightly tweaked rules for the supercolor setting when doing a NiGHTS transformation, but only meaningful for setting FF_FULLBRIGHT.
* if you can turn SF_SUPER, flash your skin's supercolor, otherwise be your normal color
* if your skin doesn't have a SPR2_NGT0 (horizontal fly), use Sonic's (this will hopefully be replaced by 2.2 with sprites of NiGHTS themselves)
* MT_NIGHTSCHAR made irrelevant, everything follows actor->target instead of actor->target->tracer now
* emerald is now player->mo->tracer instead of player->mo->tracer->target
* nightopian helpers flash for the 35 tics before they disappear
* nights capsule makes boss explosions/noises now (i can change it back i just like it better)
* drill off into the sky instead of fly up in floating pose (but no noise yet)
ALSO:
* default maxdash is now 70
* forgot to add supercolor to lua, it is there now
* SPR2_SMSL renamed to SPR2_SSTN (stun)
* any player with a skincolor that's in the super range is set to FF_FULLBRIGHT at state-set time, so no need to keep super players non-fullbright just because they use spin stuff
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
