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
Fixes and changes related to the act of setting up a level (in other words, setup fixes)
Changes made in this branch so far:
* a REJECT lump of zero length (NOT to be confused with a REJECT lump of non-zero length with all-zeros, just to clarify) should no longer cause problems with netgames and otherwise. The game now checks if the lump exists, has the right name, and length is not zero - if it fails any of these, the REJECT lump is not loaded and P_CheckSight won't be allowed to use it. This means ZDBSP (no reject) should be safe(r) to use now!
* there's now a simple devmode-only message (requires "Setup" mode) if a sector is found to have no lines at all during setup. It's a far cry from the plot to I_Error the game I once had for that unsusal scenario, but such a level still works anyway so whatever.
See merge request !87
FF_REVERSEPLATFORM clipping
Ran into an issue whilst testing out one last feature (there's always one more...) for flat_alignment_revamp. This is a backported fix.
The bug was such that if you're falling through a platform with FF_REVERSEPLATFORM and not FF_PLATFORM, you'll be pushed downwards such that your head is against the bottom of the FOF. This just checks momz is greater than zero if it has FF_REVERSEPLATFORM to make sure it's okay to set ceilingz. (OR the alternative in reverse gravity.)
No test map because this was originally done for internal. Instead, test it on the other branch's test map.
See merge request !83
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
Also, the teetering angle on slopes is now FRACUNIT/2 because there's literally no way to stand still on a slope that steep unless it doesn't have physics.
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.
This should mean that maps built with ZBSDP (no reject) should have less or no problems in netgames compared to the standard ZenNode maps now, hopefully. =)
note: once this is merged into internal, you should probably remove me from "programming assistance" so i'm not duplicated for no clear reason. unless you want me to slowly take over every section in the credits >:3c
"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.
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
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
Basically this makes sure numwadfiles is updated before loading the SOC/Lua scripts, so if a Lua script calls COM_BufInsertText with the contents "addfile scr_mysticrealm.wad" it can't overwrite the last written wadfile slot! Not that COM_BufInsertText really should be used like that to begin with
*Didn't take into account object scale
*Doubled force when on the ground (ignore what the comment of the line I moved says, it was relevant for slopes...)
This also led to a mistake with slopes, where I was double-multiplying by the gravity constant to get half (because of a quirk of numbers...)
