Commit graph

1292 commits

Author SHA1 Message Date
Monster Iestyn
22b76c9fa3 Initial efforts towards reverting 2.1.15's changes to lower unpegged, in both renderers 2016-07-09 21:15:13 +01:00
Inuyasha
331ea9814f version numbers, etc 2016-06-29 20:01:22 -07:00
Inuyasha
26b3f2e0dc Merge branch 'toast_slopes' into 'next'
Some slope improvements/fixes (plus P_GetMobjGravity)

Dear Red, I did some things.

* Made the slope flag SL_NOPHYSICS actually have an effect like we wanted to, but didn't get around to implementing yet - activated by setting the slope's linedef flags to have ML_NOSONIC.
* Made downhill slope thrusts proportional to an object's gravity and friction.
* To make the above happen - seperated out the gravity value finding code in P_CheckGravity into a seperate function, P_GetMobjGravity. (p_mobj.c, p_local.h) I also made this function available to Lua.
* Turned those PANIC n console messages (which would inevitably be followed up with a crash, since we're accessing invalid memory immediately after) into a descriptive I_Error.
* Put the SRB2CB type-shimming behind an ESLOPE_TYPESHIM ifdef.
* Removed SPRINGCLEAN-ifdef'd code.
* Cleaned up some eosteric comments.
* NEW SINCE RED +1'd THIS: The teetering code now takes slopes into account pretty well. There are edge circumstances as outlined in commit 9d221f4f3f, but this is unilaterally better behaviour in every way and the teetering code was kind of a mess anyways.
* NEW SINCE RED AND ALAM +1'd THIS: P_ReverseQuantiseMomentumToSlope. Simple function that replaces the inverse angle stuff (which also wasn't using InvAngle, just ANGLE_MAX - angle - which is inaccurate!!)

Current testing files available at /toaster/slptst3.wad and /toaster/gravitytest.lua on the ftp.

I want to do more to the branch like implement SL_ANCHORVERTEX in the near future, but this is probably safe to merge in its current state.

See merge request !77
2016-06-22 19:03:58 -04:00
Inuyasha
a938efa328 Merge branch 'climbing_shit' into 'next'
Climbing on one-sided linedefs

Does what it says on the tin. You couldn't before, now you can.

With this branch, thok barriers are now completely optional for maps with no aesthetic need for sky-topped walls. All the bugs and complications that exist with climbing right now still exist, except now there's one less issue making them suck forever and now Nev3r will be very happy.

Do I need a testing .wad? It's... not that hard to create a very small map and go nuts with Knuckles in it. I have one, but uploading it to the ftp almost feels insulting.

See merge request !90
2016-06-22 19:02:00 -04:00
toasterbabe
f93b31f0a7 FUCK C90 2016-06-20 02:08:07 +01:00
toasterbabe
20ffbbdc41 Climbing now supports one-sided linedefs.
The whole thing needs a refactor in general, but it's almost 2am here, I need my sleeb, and this fix would probably break something with 2.1 climbing if I made it any more/less (depending on viewpoint) complicated.
2016-06-20 01:50:47 +01:00
toasterbabe
71f5d4ea85 ...completely misunderstood the reasons we weren't merging toast_slopes, mom holy fuck i'm stupid and bad
Enjoy your slopes without physics, people :D
2016-06-20 00:20:20 +01:00
Alam Ed Arias
95269ab44b Merge branch 'master' into next 2016-06-19 12:53:11 -04:00
Alam Ed Arias
6f4c52c993 travis: treat warnings as errors 2016-06-19 12:51:56 -04:00
Alam Ed Arias
e87e747a29 clean up warning done in setup-fixes 2016-06-19 12:48:35 -04:00
toasterbabe
86721f1457 Compilation fix of the patch to disable this feature ( :c ). 2016-06-19 17:29:04 +01:00
toasterbabe
fa58993bda Merge branch 'next' of http://git.magicalgirl.moe/STJr/SRB2.git into toast_slopes
# Conflicts:
#	src/p_user.c
2016-06-19 16:59:49 +01:00
toasterbabe
1147428904 Revert "Changed teetering to match the discoveries made about it in the sectorlist_traversal branch in a way that matches my revamps here, since I DID change a lot."
This reverts commit 19b186e52e.
2016-06-19 16:38:11 +01:00
toasterbabe
f5f2c4ad48 Revert "Okay, NOW I fixed the compile error. Forgot to stage this."
This reverts commit 1723bb55f9.
2016-06-19 16:38:04 +01:00
Alam Ed Arias
8e98c78456 Merge branch 'next' (early part) into toast_slopes 2016-06-19 03:39:42 -04:00
toasterbabe
3fe87eff97 Disabling the functionality of SL_NOPHYSICS for 2.1 patches by never applying it 2016-06-18 23:55:43 +01:00
toasterbabe
9c277bfb22 Merge branch 'next' of http://git.magicalgirl.moe/STJr/SRB2.git into toast_slopes 2016-06-18 22:58:24 +01:00
Inuyasha
8fc61bb674 Merge branch 'sectorlist_traversal' into 'next'
Sectorlist traversal

MOM GET THE CAMERA

There's a LOT of code in the source that ended up mixing m_snext (the node for the next thing in the sector's thinglist) and m_tnext (the node for the next sector in the thing's sectorlist), so I renamed the following:

* m_snext ==> m_thinglist_next
* m_sprev ==> m_thinglist_prev
* m_tnext ==> m_sectorlist_next
* m_tprev ==> m_sectorlist_prev

Then, I changed all the instances where the code was trying to go m_thinglist_next on a mobj's touching_sectorlist (which would've just gone to the node for the next thing in the same sector, instead of the node for the next sector for the same thing). Notable samples:

* FF_SHATTER blocks now disappear the moment you go into their sector. You still can't give FF_SOLID to them because in that case they will still stop you if you never enter their sector at all (ie - clip on corners), but having them nonsolid no longer allows you to phase through entirely without busting them (which was the whole downside of making them intangible in the first place).
* You can now bump into multiple Mario blocks at a time, even if you're not exclusively in their sector.
* No more getting randomly stopped on the edges of bouncy FOFs.
* Landing on polyobjects might behave a little more consistently at the edge of their host sector.
* Teetering did a SHITTON of code that basically never got executed, and then had directly-blockmap-accessing code as a backup. The code was activatable by replacing the m_thinglist_next with m_sectorlist_next, but it behaved SUPER differently from what we're used to with teetering (if the player mobj's edge was JUST off the edge of a platform, you ended up in teetering frames - even if it looked like you could stand) so I ended up removing that section entirely.

Any objections?

See merge request !85
2016-06-18 16:52:21 -04:00
Monster Iestyn
9e31ab1393 Merge branch 'master' into next 2016-06-17 14:44:23 +01:00
Inuyasha
307129f7c9 Merge branch 'other-software-fixes' into 'master'
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
2016-06-17 08:06:19 -04:00
Inuyasha
ee180807d1 Merge branch 'setup-fixes' into 'next'
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
2016-06-17 08:05:09 -04:00
Inuyasha
191a4bc7d2 Merge branch 'reverseplatform_clipping' into 'next'
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
2016-06-17 08:01:03 -04:00
Monster Iestyn
df55019d40 Merge branch 'master' into other-software-fixes 2016-06-13 21:13:51 +01:00
Monster Iestyn
9ae2a4036a Merge branch 'master' into next 2016-06-13 21:10:53 +01:00
Monster Iestyn
9b037164bc Added debug messages for when REJECT lump is not loaded 2016-06-12 21:51:27 +01:00
Monster Iestyn
f94dd510ad change back to 8, add \0s 2016-06-12 21:16:41 +01:00
Monster Iestyn
b4798538e2 Merge branch 'software-fixes' into 'master'
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
2016-06-12 14:33:27 -04:00
toasterbabe
2c676eea43 P_ReverseQuantiseMomentumToSlope is now a function. (I was thinking about a macro, but couldn't get it down.)
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.
2016-06-12 19:27:34 +01:00
Monster Iestyn
305d32870f 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.
2016-06-12 18:47:27 +01:00
Alam Ed Arias
472dce1ae6 Do not why we are not checking REJECT\0\0, let fix this check 2016-06-11 21:42:02 -04:00
Monster Iestyn
1d0e74f9c0 "REJECT" is only 5 chars long, not 8. 2016-06-11 21:19:16 +01:00
Monster Iestyn
a7a7a7ee6d Added P_LoadReject function to properly check if REJECT lump is valid or not when loading it, so P_CheckSight can avoid accessing it if not.
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. =)
2016-06-11 18:45:56 +01:00
Monster Iestyn
df92dc8d9e Print debugging message if sector->linecount is zero 2016-06-11 16:14:08 +01:00
toasterbabe
9e87f6d85d i did so much in this branch, so UPGRADE ME TO PROGRAMMER
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
2016-06-10 22:45:42 +01:00
Monster Iestyn
a04fcce3a9 Hack to fix midtextures for polyobjects being mucked up
"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.
2016-06-09 22:07:43 +01:00
Monster Iestyn
20c2d84c78 Fix single side line midtexture skewing
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?)
2016-06-09 20:37:36 +01:00
toasterbabe
661da15146 Reinforcing encapsulation I originally broke down to allow for P_GetMobjGravity.
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.
2016-06-09 18:16:13 +01:00
toasterbabe
1723bb55f9 Okay, NOW I fixed the compile error. Forgot to stage this. 2016-06-09 15:24:23 +01:00
toasterbabe
c5ff41d6a6 Fixed compile error and placed the #undefs for xsign and ysign in more logical places. 2016-06-09 15:20:45 +01:00
toasterbabe
19b186e52e Changed teetering to match the discoveries made about it in the sectorlist_traversal branch in a way that matches my revamps here, since I DID change a lot. 2016-06-09 15:16:25 +01:00
toasterbabe
7af14c20ed Everywhere in the code that was doing things wrong has been changed.
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.
2016-06-09 14:56:24 +01:00
toasterbabe
17e0adcbac Renamed some struct variables so the problem this branch sets out to fix is more obvious at a glance.
* m_snext ==> m_thinglist_next
* m_sprev ==> m_thinglist_prev
* m_tnext ==> m_sectorlist_next
* m_tprev ==> m_sectorlist_prev
2016-06-09 14:16:02 +01:00
toasterbabe
0b920ee249 You know that problem where you bumped on the edges of Mario blocks and Bustable blocks and Bouncy FOFs sometimes? Wham. Bam. In the van.
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.
2016-06-09 00:02:50 +01:00
Alam Ed Arias
742353d0ab Merge branch 'master' into next 2016-06-08 15:06:17 -04:00
Alam Ed Arias
6d2d48f152 Merge branch 'skybox-sprites-fix' into 'master'
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
2016-06-08 14:05:06 -04:00
Monster Iestyn
29ea733ae5 Fix sprites in skyboxes not having clipping arrays actually set properly 2016-06-08 17:53:34 +01:00
toasterbabe
51c769247a Compiling fixes. 2016-06-07 19:44:43 +01:00
toasterbabe
aa113045d7 MI pointed out opportunity for more optimisation, and who could resist? 2016-06-07 18:18:47 +01:00
toasterbabe
9df72a966e Some simplifications after MI pointed out that the sector heights are the only thing accessed outside of the iteration. 2016-06-07 17:55:03 +01:00
toasterbabe
9d221f4f3f Teetering now supports slopes properly.
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
2016-06-07 17:37:25 +01:00