Slope fixes
This branch fixes the following slope-related physics and rendering bugs:
* Rings in multiplayer stages respawning inside slopes (even despite being able to spawn ABOVE them on map load)
* Player starts spawning players inside slopes
* Elemental flame trails not appearing if a player spindashes UP a slope; see issue #21
* Dying players "jumping" off slopes to the side if they were previously standing on one
* Some issues with FOF slope rendering
* Various issues with sprites displaying through walls adjacent to slopes
Other features added:
* Objectplace now supports slopes (this is Inuyasha's doing)
* Automap in DEVMODE now supports slopes (my doing)
Just making this merge request now rather than later, ~~in case I decide not to make any more fixes for the time being~~ (this branch doesn't seem to want to die lol), and so we can get these merged in as soon as the code's all been checked over.
See merge request !50
xorshift* PRNG
This needs testing to ensure I didn't mess anything up switching function names around.
Our PRNG sucks. This is probably obvious. I wish I had known better at the time I implemented it, but oh well.
The replacement is an xorshift* PRNG variant with period 2^32 - 1 (meaning that the PRNG state will loop after four billion calls ... that's not likely to happen), versus the old PRNG's period of about 2^22 (?). The output is also much more random and less predictable; the old PRNG would fall into a predictable loop of output after about 4000 numbers were generated, which isn't much.
The PRNG here also outputs numbers as fixed point from [0,1) (that's 0 to FRACUNIT-1, in other words) instead of single bytes at a time. This makes it much easier to calculate things for, say, P_RandomRange and P_RandomKey. A new macro, P_RandomChance(p), is now in use that returns true _p_ percent of the time, where _p_ is a fixed_t probability from 0 (0%) to FRACUNIT (100%).
This doesn't affect netgames at all; the code for seed saving and restoring is identical (aside from a check to prevent seed being set to 0, which breaks xorshift PRNGs). Demos break, but A: _duh_ and B: they're already broken by all the changes to physics to accommodate slopes.
P_Random is deprecated in Lua, as the function was renamed to P_RandomByte. Aside from that, nothing special.
See merge request !64
Fix for teetering on PolyObjects
So... somebody goofed and didn't realise PolyObject sectors could be added to the sector node list for each object (which is referenced by mobj->touching_sectorlist), via their linedefs if they are nearby the player (yes, PolyObject linedefs are special and get to move about the level). As it turns out, this allows even INTANGIBLE PolyObjects to make you teeter in a seemingly inexplicable way.
What is happening is that PolyObject sectors, when they are added to the mentioned lists, are then checked under normal sector teetering conditions - if the player is above the floorheight by 24 FUs, you're officially teetering unless stated otherwise. The actual PolyObject teetering code can't help you here if the conditions are right, especially if they're taller than 24 FU in height.
There are a number of things wrong with the teetering code in general that I'd like to sort eventually, but at least now teetering on PolyObjects is fixed at last ...right? Please check the branch out if you can to check this, obviously.
See merge request !54
P_RandomChance is now a macro for something that should happen a
certain percentage of time.
P_SignedRandom was moved to a macro. Nobody cared.
# Conflicts:
# src/p_inter.c
BACKPORT: removal of music slots
Relevant commits cherry-picked. Basically everything except the internal music track name switches.
See merge request !43
Use whatever names you want for your music. So long as you prefix the lumps with O_ or D_, it doesn't matter anymore.
DISCLAIMER: Linedef type 413 (change music) and Lua scripting is not tested.
(cherry picked from commit 025ca413a2)
# Conflicts:
# src/p_user.c
Fixed one of Red's mistakes, and used a different struct variable for dashmode. This needs to be changed though, because everything will break if someone loads a circuit map.
Rob request player anims
[21:44:35] <@Rob> As far as I can tell the player-anims that I requested work
[21:44:45] <@Rob> That can probably be merged at this point
See merge request !22
* SPR2_JUMP and SPR2_SJMP are now the jump sprite sets for spin chars
* SPR2_SPNG and SPR2_SSPG are the new sprite sets for spring up anims (instead of JUMP/SJMP)
* S_PLAY_JUMP and S_PLAY_SUPER_JUMP are now the states for spin char jumps
* S_PLAY_SPRING and S_PLAY_SUPER_SPRING are the new states for spring up (instead of the "JUMP" states)
* PA_JUMP is now PA_SPRING (jumping anims are lumped with PA_ROLL)
Compiling errors fixed in this commit:
* Various cases of mixed declaration and statement code
* Implicit declaration of slope functions (read: you forgot to put "include "p_slopes.h" in MORE than a few places)
* an odd case of a bad fixed_t to float typecase, cause by using P_GetZAt directly inside FIXED_TO_FLOAT
* a few minor cases of bad unsigned-signed comparisons
* no prototypes for some of the new slope functions. For goodness sake Red, this is basic stuff!
This works fine in single player on vanilla builds, multiplayer is untested. This might not be the best way to handle the ability, so modifications for efficiency/sanity might be necessary.
Compiling errors fixed in this commit:
* Various cases of mixed declaration and statement code
* Implicit declaration of slope functions (read: you forgot to put "include "p_slopes.h" in MORE than a few places)
* an odd case of a bad fixed_t to float typecase, cause by using P_GetZAt directly inside FIXED_TO_FLOAT
* a few minor cases of bad unsigned-signed comparisons
* no prototypes for some of the new slope functions. For goodness sake Red, this is basic stuff!
New player animations (Updated player.dta Sonic)
Adds support for several completely new player animations, mostly for Super Sonic.
See merge request !5
Assume that every frame the player is on the ground, their pmomz will
be re-set properly if the floor is moving, therefore if the platform
STOPS, we need this to set it to 0.
Here's how it works: When a player walks off the
moving platform, it applies their pmomz once, and
then _keeps pmomz set_ so that the camera still
adds pmomz to its movements until they hit another
floor. This way, the camera doesn't jerk around.
Now players will apply platform movement when jumping,
but only if the platform is moving the same direction
as their jump is, and all other objects will have an
appropriate pmomz in reverse gravity FOF situations.
These functions were already here before, and I /swear/ the slope
physics became slightly less glitchy after switching to them...
Only issue is the slope plane mapping code hasn't been properly
converted yet, so they don't render properly for now.
Your acceleration vector parallel to the slope is reduced based on slope
angle if it's going up the slope. The pull physics' momentum increase was
toned down a bit to go along with this. Also, I removed the ifdefs for
OLD_MOVEMENT_CODE because why should that be kept around?
