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.
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.
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
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)
* Actively impede your acceleration
* Make your animation speeds faster whenever you're moving (to give off that Looney Tunes effect)
The former change is something that was present in the few low-friction circumstances in the classics, and makes low-friction surfaces more of an active challenge. The latter change is just something I did for fun to more clearly communicate that things are different with the physics here.
High friction surfaces DO NOT involve any of this, since it ended up basically cheesing their existing gameplay.
*Friction linedef effect is now -
1) controlled by x offset instead of length - offset of -100 is maximum iciness, offset of +483(!!!) is the maximum sludginess BUT things are scaled such that +100 is about the maximum sludginess any reasonable human being would want in a level, 0 is ORIG_FRICTION)
2) not reliant on a sector special to function (can be applied solely by tag to in-map sectors or solid FOF control sectors)
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...)
Also took the opportunity to nuke or otherwise neuter a bunch of Kalaron's bizzare ramblings (most are questions which have long-been answered by Red's efforts) at the same time.
*The No Physics flag now works (Red, you might want to doublecheck this to see whether I haven't missed any eosteric stuff out). Going downhill is a little bumpy, and I'm not sure whether that's good or not. Someone help me out here?
*The SRB2CB typeshims are now behind #ifdef ESLOPE_TYPESHIM instead of #if 1 for easier disabling.
*Slopes' downhill thrusts are now scaled with regards to object gravity. This is actually untested in gravities other than normal and reverse normal but it's one line which can be easily reverted in that circumstance. I also checked with MI to make sure this is how it's calculated elsewhere, so fingers crossed this doesn't cause any edge cases.
*As a consequence of the above point, there's now a function in p_mobj.c/h that returns an object's internal gravity - seperated out from the logic of P_CheckGravity, which really didn't need to be so monolithic. Multiply by global gravity to get the thrust. This should probably be available to Lua somehow, but I have absolutely no idea where to start with that. Wolfs, maybe?
Non-comprehensive test file available at /toaster/slptst3.wad on the ftp.
Do we really need to keep it around? If not, I say get rid of it. It seems like useless clutter that is just going to confuse people who are trying to understand the source code.
* -lSDL2_mixer is already added to SDL_LDFLAGS by default, unless NOMIXER=1 is set
* -DSDLMAIN should also be added to OPTS by default for MINGW=1 builds, unless NOSDLMAIN=1 is set
NiGHTS hotfix
Fixes the following issues relating to playing as NiGHTS Super Sonic that apparently popped up between 2.1.14 and next (mostly due to the changes to SRB2's trig stuff it seems):
* Super Sonic drifts to the side at some angles around an axis, and is unable to go directly upwards or downwards as a result
* Drilling to the side when on the ground causes the drill sound to constantly restart
* CEZS's start not actually being lined up properly with the first axis means the player is not able to go backwards along the track (because the player is not actually aligned with the track properly, preventing you from touching the attached line transfer)
* trying to hug some walls such as the tall wall before the library section of CEZS allows Super Sonic to go through them
These fixes needs proper testing before this branch can be merged in, in case they accidentally break other things as a result or something.
See merge request !71
Basically I kind of worked around any potential trig inaccuracies by not using the player position directly for setting momx/momy. This way, if player->angle_pos == player->old_angle_pos, momx/momy are zero
Demo replay fixes
Changes made/bugs fixed in this branch:
* Replay camera is now controllable when climbing (https://mb.srb2.org/showthread.php?t=38668), and in waterslides
* localangle (read: the angle between you and the camera, I think) now doesn't change during demo replays in most situations, unless the player is in analog mode. Exceptions include zoomtubes and NiGHTS super
* Replay camera now doesn't act silly if the player is in analog mode (assuming you also recorded it in that mode to begin with, anyway)
See merge request !66
DO NOT MERGE THIS INTO THE INTERNAL REPO. This is a temporary 2.1.15 only fix. This commit allows an optional boolean for tan(), which when true will automatically shift angles by ANGLE_90.
the most common condition (correct drawing) shouldn't be last, however it can't be first without making the conditions longer anyway.
it's a nitpicky thing, but this is the renderer we're talking about here.
i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs
Previous overflow fix resulted in extra tall FOFs disappearing up close (see: ERZ1's elevators at start)
This works "better" in that only some lighting bugs and really really finicky visual glitches show now. I give up trying to totally fix this stuff dfsdfgdgf
One more name in the credits
I probably messed up by making toast_credits based on master instead of next. If that's blocking, just delete this branch and I'll re-do it. It's a single line, though - shouldn't exactly matter so much.
Could probably stand to be merged into Internal as well, since I hadn't actually worked on any textures when we'd updated the credits there.
See merge request !69
Fix portal and plane/sky interaction
More portal-related fixes:
* Fixes rendering issue 4 from issue #21 (Slope planes render with wrong height values when visportals are visible on-screen)
* Fixes sky rendering through portals, so that the sky you see through each portal is what you'd expect to see if you were actually there. Easiest way to see what I mean is through sky 22's planet, in a map with portals at 90 degrees to the other sides respectively (the example map on the wiki for ld40, for instance).
See merge request !65
The idea is for the layman Lua user to understand better what range of values to use for mobj types, states, sfxs, player #s etc. Additionally, mobjinfo/states/sfxinfo/hudinfo tables all now have actual bound checks when accessing/editing them. Yikes, why didn't they have any before?!
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
* add skidtime, which we forgot before 2.1 release apparently
* change tics from INT16 to INT32
* change eflags from UINT8 to UINT16
* change actionspd/mindash/maxdash from INT32 to fixed_t
Until we use something besides Native MIDI to play
back MIDI music, MIDI volume changing is disabled
since it causes way too much of a damn headache.
(It's not even our fault, it's fucking MS.)
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
Fixes for patch scaling and V_FLIP usage
The following issues are fixed by this branch:
* a patch using both scaling and V_FLIP does not appear in the "correct" place on the screen. Thanks to LJSonic for pointing this out to me on 'fun
* Scaled and/or V_FLIPed patches wrap at the left/right screen edges even though they're not supposed to. V_FLIP patches at these edges may also crop the wrong side of the patch if they're at the right edge.
See merge request !60
Some fixes for portals
Specifically the following things are fixed in this branch:
* a memory leak resulting from not clearing away clipping-related arrays each tic you view a portal
* a very specific crash to do with portals sometimes (unintentionally) using a hack on drawsegs that don't actually belong to them ...which results in a crash if the drawsegs in question have midtextures. I reported it on the MB a year ago, with a test map included there: https://mb.srb2.org/showthread.php?t=38199&page=4#79
* another specific crash to do with mirrored (horizontally flipped) sprites that are scaled, particularly when you cover up the left edge of them via portals at the least. Needs more testing to be absolutely sure this is fixed, and is also reproducable in the test map linked in the post above
May be fine to merge changes into master too, I don't really know exactly
See merge request !42
Camera fix
This fixes the third person camera being silly around intangible PolyObjects, particularly the fact they can affect the camera's floorz and ceilingz even though I see no reason why they should do so.
Also a good reminder that POF_SOLID is the same as POF_CLIPLINES and POF_CLIPPLANES combined, which is probably how this issue came about to begin with. Can't say that with certainty of course.
See merge request !57
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
This actually passes most diehard tests, as opposed to the old RNG.
It's also similarly fast.
Internally the PRNG generates a fixed point number from [0,1) now,
which makes P_RandomKey and P_RandomRange much easier to
calculate. P_Random is just a simple shift, as well.
Also, the lack of floating point math in P_RandomKey and
P_RandomRange now is probably for the best.
Also makes comptime.bat work with git if able.
Development builds will now show the branch and the SHA1 hash of the revision. Also been tested to work with subversion, where it displays "Subversion r####". You know, just in case.
There is a caveat to this: The first time EvalMath is used, a
deprecated function warning will be shown to the user that tells
them to use _G[] instead.
This reverts commit 9d36cf37bd.
This appears to fix a few holes that have been known to appear with FOF slopes sometimes, dunno how they actually came about exactly but this apparently sorts them out
Lua sector lines
Adds support for "sector.lines" in Lua, an array containing all the linedefs in a particular sector variable:
#sector.lines returns the number of lines in the sector.
sector.lines\[ _i_ \] (e.g. sector.lines[0], sector.lines[1], sector.lines[2], etc ....) gives you individual linedefs in the sector. If the number you supply is equal to or greater than #sector.lines, this returns nil.
Test script for your benefit: (see comments)
Type "luatest" in console in any level and you'll get a few print messages that tests these features for sectors[0]
See merge request !32
SOC_**** lump name support
Exactly what it says on the tin: lumps with "SOC_" prefix now are read as SOC lumps like with MAINCFG/OBJCTCFG. Go nuts.
As a bonus, I've changed things with SOC lump detection so MAINCFG, OBJCTCFG and the new SOC_**** lumps are loaded in the order you find them in WAD files (rather than an arbitrary load-MAINCFG-then-load-OBJCTCFG thing as before). All of these are still loaded after Lua scripts though, mind.
See merge request !38
Lua video lib expansion
New video/drawer library functions for hud.add to use:
v.width() and v.height() return the screen width and height respectively (in other words you get the screen resolution), while v.renderer() returns the string for the renderer used ("software", "opengl", or "none").
Possibly add more stuff later, but for now these things at the least can be merged in next
See merge request !40
Add PlayerSpawn hook to Lua
I don't know how I did this but I did. Something about staring at code from 3AM till 5AM...
Here's a test script too:
```Lua
addHook("PlayerSpawn", function(player) player.health = 99 end)
```
See merge request !48
Version constants for Lua
Pretty simple thing. Allows scripters to use VERSION, SUBVERSION, and VERSIONSTRING to check the game's version and potentially futureproof scripts. Have tested and confirmed working on my end.
See merge request !55
BACKPORT: removal of music slots
Relevant commits cherry-picked. Basically everything except the internal music track name switches.
See merge request !43
The funny thing is you really can't see ANY change here unless you have a sloped FOF intersecting a sector floor/ceiling (and a second FOF on the other side), which has other problems anyway lol
BACKPORT: FF_ANIMATE simplistic state animations
this is a lot more complex due to the need to remove the dispoffset related code as well as a lot of the redefinitions; combined with the code changes due to the sprite2 system in internal master.
~~BEFORE ACCEPTING THIS: get sryder to look at and fix any possible brokenness with OpenGL MD2s~~
See merge request !45
Fof flag change hotfix
This fixes rendering issues caused by changing FOF flags mid-level via Lua or linedef type 445. Everything else that toggles FF_EXISTS already had this fix it turns out.
Not sure if this is safe for master too, could someone check that for me?
See merge request !53
This fixes how removing certain flags (such as FF_EXISTS) from FOFs can cause HOMs on walls bordering their target sectors. Also fixes how the force-FOF-to-vanish linedef special can leave behind the FOF's shadow
Fix chain launching
Basically you're not allowed to launch off a chain the frame you touch it anymore.
Coincidentally the changes here allow you to actually use PF_*STASIS in a Lua script now and have it work as you'd expect it to (it lasts for a tic).
See merge request !49
cpuaffinity/sdl_mixer changes
Hopefully this will alleviate SDL2 sound issues.
If not, hopefully this will give us info on what the hell is going on.
See merge request !51
(No, game, you can't allocate a map header for the credits, why were you doing that before and how did it not break anything??)
(cherry picked from commit e1f9a01229)
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
Travis-CI builds
Merge support to build SRB2 for Linux system via Travis-Ci
This will build SRB2 with GCC and Clang to make sure we do not break Linux/GNU builds
See merge request !41
Monster Iestyn's Miscellaneous (netplay-compatible) changes
Just cleaning up some unused or unnecessary things left in the source code, see the commits for exact changes made if you like.
May add more stuff to this branch later, there's no rush really.
See merge request !39
Diagonal spring rings tweak
If you didn't know before, those special placement ring lines for diagonal springs only use multiples of 45 for their angles in-game. In other words, they only face any of the 8 basic cardinal directions (N, S, E, W, NE, NW, etc). Considering that springs themselves don't follow the above behaviour, you can probably work out that's a bad thing.
This branch changes that of course, if you couldn't guess from context. Diagonal spring rings can now be placed with any angles like most thing types already could!
See merge request !37
some of the mess in here really bothers me
(cherry-picking this commit of mine from next since it only fixes a small oversight with compiling and adds a comment)
the screen texture does not need an alpha channel.
the fact that it had one made OGL copy the topmost pixel of the screen texture's alpha channel.
which, naturally results in the screen becoming partially transparent and letting you see the working texture in the background.
g_game.c: In function 'G_CheckDemoStatus':
g_game.c:5588:22: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
if (!modeattacking == ATTACKING_RECORD)
^
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.
This is not how you use pushlstring! This is actually sending uninitialized memory to Lua, which is making scripts have inconsistent results (duh?)
c/o JTE: "Tell Red they're a doofus."
Admittedly I knew of this particular method from the start but wanted to avoid it in favour of a less-hacky looking method of getting sector.lines' size ...but there was none to be found at all.
Coloropposite hotfix
Quick fix to prevent ColorOpposite(MAXSKINCOLORS) or higher input from giving results out of the actual array's bounds. In other words, preventing it from giving you nonsense values or something.
I created the function for Lua to begin with, so clearly this is 100% my fault once again. Welp.
See merge request !31
Objectplace reallocates the mapthings list to add one more mapthing. By itself there's no problem with this.
But, mobj->spawnpoint is a pointer to the mapthing's location in the mapthings list.
So by reallocating the mapthings list, all references to mobj->spawnpoints point to freed memory.
... Oops.
Now when objectplace reallocates the mapthings list it actually corrects the locations of all mobj's spawnpoints to point to the new list.
Hooray, you can use NiGHTS objectplace again if you really want to.
Objectplace reallocates the mapthings list to add one more mapthing. By itself there's no problem with this.
But, mobj->spawnpoint is a pointer to the mapthing's location in the mapthings list.
So by reallocating the mapthings list, all references to mobj->spawnpoints point to freed memory.
... Oops.
Now when objectplace reallocates the mapthings list it actually corrects the locations of all mobj's spawnpoints to point to the new list.
Hooray, you can use NiGHTS objectplace again if you really want to.
The point here is ColorOpposite(MAXSKINCOLORS) would have given an actual result of its own since MAXSKINCOLORS & MAXSKINCOLORS is still MAXSKINCOLORS. This shouldn't happen though, as both Color_Opposite[MAXSKINCOLORS*2] and Color_Opposite[MAXSKINCOLOR*2+1] aren't defined.
Note: polyobj_t's "translucency" is apparently a SIGNED integer, so in theory it's possible to get polyobj flats to use the "spanfunc = splatfunc" line using negative values. If this is not meant to happen, this should probably be fixed asap
Conflicts:
src/f_wipe.c
Also makes comptime.bat work with git if able.
Development builds will now show the branch and the SHA1 hash of the revision. Also been tested to work with subversion, where it displays "Subversion r####". You know, just in case.
Also makes comptime.bat work with git if able.
Development builds will now show the branch and the SHA1 hash of the revision. Also been tested to work with subversion, where it displays "Subversion r####". You know, just in case.
more detailed description: vissprites now store dispoffset in a separate variable from (y)scale, and uses it to influence order between sprites without it affecting the actual drawing of the sprites themselves
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
Monster's miscellaneous meddling
A miscellaneous assortment of code-cleanup and other changes, plus fixing up SRB2's tangent array so it behaves more as expected (especially on the Lua side).
More specific details of the changes:
(MUST-HAVE CHANGES)
* `finetangent[]` has been entirely redone in the same manner as finesine/finecosine.
* Lua's tan() function shifts `finetangent[]` results by `ANGLE_90` to get what you EXPECT it to return (e.g. `tan(0)` actually returns 0 now). This means finetangent itself doesn't need to change its general arrangment, this only affects Lua specifically.
* Lua's tan() function now also doesn't go out of `finetangent[]`'s bounds at all. Before, `tan(ANGLE_180)` through `tan(ANGLE_MAX)` and such would just give you values unrelated to the array in question, which was clearly a bad thing.
(CAN PROBABLY LIVE WITHOUT?)
* `finecosine`'s definition moved from r_main.c to tables.c.
* Created `P_CheckTimeLimit` for `cv_timelimit`, much like `cv_pointlimit` has `P_CheckPointLimit`. It cleans up `P_UpdateSpecials` a bit at least.
* Some code cleanup relating to translucency maps - these are kind of unimportant, I was about to stop `FF_TRANSMASK` being used everywhere, but this was apparently a bad idea so I backtracked a bit.
* Re-added `_MSC_VER` check around MSVC-specific code in doomtype.h, in case it wasn't defined (and `__OS2__` was). Also left a comment there regarding `__BYTEBOOL__`.
* Fixed an apparent copy+paste goofup in `joyaxis_cons_t[]` for the Wii-specific code.
See merge request !10
Fix md2s
shoutouts to MI for breaking them accidentally
I was about to just commit this straight to next but it's the perfect reason of why code review is beneficial and I'd be a hypocrite to point that out and then skip the process
See merge request !28
Reduced palette
You guys should know what this is by now. If you don't, you really need to catch up. =P
We should check with toaster and others involved to check this thing is actually ready to go though, the number of changes to the palette itself over the last year has been absurd.
See also http://git.magicalgirl.moe/STJr/SRB2Internal/issues/8
See merge request !13
Apparently all parts of the source code that require GLPatch_t are themselves used only if HWRENDER is defined. Do I need to say more?
Not sure if this will fix Wolfy's latest problem or not though
Basically, Wolfy's linux (non-CMake) compiling apparently fails here, and config.in.h actually lives outside of the sdl folder. Blame a particular someone for blindly copy+pasting these includes in this file without considering the consequences when adding support for CMake everywhere.
Apparently all parts of the source code that require GLPatch_t are themselves used only if HWRENDER is defined. Do I need to say more?
Not sure if this will fix Wolfy's latest problem or not though
Basically, Wolfy's linux (non-CMake) compiling apparently fails here, and config.in.h actually lives outside of the sdl folder. Blame a particular someone for blindly copy+pasting these includes in this file without considering the consequences when adding support for CMake everywhere.
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.
1up icons were spawning their overlays off sync with each other so the face icon was showing up during static. Now they don't.
(They'd do this in 2.1 too if you have a custom WAD added that doesn't have an overlay sprite, and you use it in multiplayer alongside a character that does.)
Dispoffset changes
Dispoffset now works in OpenGL, and the feature has been optimized so high dispoffset values don't cause sprites to be distorted anymore.
See merge request !12
* 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.
It's a lot nicer in general, honestly. I think a couple bugs with custom monitors respawning got fixed in the process.
Note that a monitorgfx.wad is needed if you want to see things besides <!>s for monitors, due to graphic changes.
Actions tweaks
This just rewrites the action A_SetTargetsTarget currently, dunno if I'll bother to tweak any more actions in the near future \*shrugs\*
That said, PLEASE check whether the action works properly before accepting the merge. It's been a while since I last did anything with this branch, so I forget entirely whether I tested it or not.
See merge request !27
more detailed description: vissprites now store dispoffset in a separate variable from (y)scale, and uses it to influence order between sprites without it affecting the actual drawing of the sprites themselves
Note: polyobj_t's "translucency" is apparently a SIGNED integer, so in theory it's possible to get polyobj flats to use the "spanfunc = splatfunc" line using negative values. If this is not meant to happen, this should probably be fixed asap
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!
Slopes and stuff
Adds support for slopes, slopes on FOFs, slopes on translucent FOFs, slopes on FOFs with holes in the flat, slope physics, dynamic slopes, vertex slopes, dynamic vertex slopes, and a ham sandwich to the game. Only for software mode right now, though. (OGL still gets the physics and the sandwich.) Some things still need to be done, but for now this can be merged in to be finished later.
Please make sure nothing in the vanilla game breaks before giving the thumbs up for this merge.
Since this doesn't merge automatically, if the code review turns out positive and nobody else has done it, I'll handle the merging.
See merge request !22
To be specific: when a sector had a sloped ceiling and a colormap was
placed above it, the colormap wouldn't fill anything above where the
ceiling height is at the sector's midpoint. This is fixed.
Oops. (Minor animation bugfix I forgot.)
Apparently I pushed this one commit to GitHub instead of SRB2Internal before the branch was merged...
Oops.
See merge request !8
*player->health (formerly the "HUD" health) is now to be known as player->rings, and now acts as the player's actual ring count
*player->mo->health (formerly rings + 1) is now always 1 when alive, regardless of ring count; if player with rings is damaged, this is untouched
Damage in normal SP/Coop gameplay has been tested and still works fine; still a lot of mess to clear up though
Tag damaging probably is broken now, I'll fix this later
Tweaks to R_PointToAngle and R_PointToAngle2
Exactly what it says in the title! See commit description for more information on what I did, since I'm too lazy to write it all up a second time. =P
Could someone check that these changes don't cause anything else in particular to go wrong in the game or source code? I haven't checked myself that much yet, mostly because I totally forgot about this thing until now, lol.
See merge request !19
Polyobj setup fixes
If you're wondering why ERZ2 crashes lately, yes, it's my fault once again it turns out! Ideally we shouldn't have loose spawn points or anchors without an actual PolyObject to go with them in the first place, but this fix re-adds the safety check that prevented them from crashing the game before.
If it wasn't clear already, this fix is rather important, so please get in asap.
See merge request !7
In Doom there was a random chance of enemies either being stunned (painstate) or instead just deciding to attack you (seetstate), but in SRB2 painstate is ALWAYS used beforehand.
New player animations (Updated player.dta Sonic)
Adds support for several completely new player animations, mostly for Super Sonic.
See merge request !5
Note: Before this change, North and West directions would be returned as ANGLE_90-1 and ANGLE_180-1. This caused the pusher polyobjects in THZ2 to slowly move sideways as a side-effect (and probably caused similar bugs in the past too, these functions have barely been touched in a decade it turns out.)
This commit makes Super floating players break into
a normal walk again when they hit the floor, instead
of keeping their float animation on the ground.
Goo Water (THZ Goop) adjustements
At Nev3r's request:
Adjusted goop so that you spend less time bouncing around in it. The goop will become a walkable surface with a higher velocity threshold.
The actual goop physics haven't been altered as far as the initial entrance and underwater time is concerned, only leaving goop and subsequent bounces has been dampened significantly.
See merge request !7
finesine table
I pasted in finesine from #11 and made a merge request.
This has been lightly tested to ensure the renderer doesn't immediately break. No ill effects have been observed so far.
See merge request !17
A_SetObjectFlags tweak
Only reset the sector/blockmap links on an object calling A_SetObjectFlags if the MF_NOSECTOR|MF_NOBLOCKMAP flags change. Fixes a freeze related to LD442 demonstrated in MascaraSnake's example WAD at https://dl.dropboxusercontent.com/u/27962790/statetest.wad .
See merge request !11
Re-add/fix broken platform momz mobj code.
The changes in this branch re-add the platform's momentum to players and mobjs which leave the platform (eg. by jumping) so that they move with relative velocity as expected. This behavior was unintentionally broken in SRB2 2.0, which adds a lot of artificial difficulty to certain segments of the levels, where you have to jump between high velocity moving platforms which seemingly cut your jump height to nothing.
Not only has the behavior been fixed, but it has now been enhanced to move the camera while free-falling between platforms as well, completing the illusion of full relative velocity with minimal hiccups. [Observe.](http://i.imgur.com/zmSfUyp.gifv)
See merge request !14
Miscellanous fixes to merge
These are the commits from the "miscellanous-fixes" branch that are okay to merge in.
Bugs fixed include the following:
* CTF flags respawning incorrectly: they cannot z position themselves correctly, and they cannot flip themselves.
* The weird "jumping" spring/monitor effect: this is the result of an internal mobj_t pointer (tmfloorthing, specifically) not resetting itself to NULL for the next object's thinker, resulting in Z movement code thrusting the object vertically at tmfloorthing->momz.
See merge request !18
... because some things (Lua. custom header entries) move it.
https://mb.srb2.org/showthread.php?t=40580
(Technically breaks netgame compatibility for Lua-heavy mods, so in next.)
That's supposed to be run once a frame, not once per hook
per mobj per frame you moron. If you just run it seven
thousand times a frame, of course your framerate will drop.
Dummy, what do you think you're doing? If you
just push mobjs and players into Lua all willy-
nilly everywhere, you'll wind up generating
tons of metatables and stuff you arne't even
gonna use!
Oh. Thanks me, I'm really smart.
This _should_ solve some significant performance
issues Lua experiences. If not, I will be very
upset for having wasted so much time and effort.
There will be bugs, this kind of thing needs to
be thuroughly tested and this is just the first
iteration of it.
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.
This fixes the issue with upside-down springs shooting downwards if you touch another of its kind. Also fixes one of the issues with monitors in Icicle Falls (after you phase inside the East-most float-bob FOF's monitor via the other bug and jump up to break it while there, the NEXT monitor moves upwards too)
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.
Also gain velocity from walking off an "up" elevator normally?
This _looks_ incorrect because the camera stops matching
the platform movement the moment you step off, but I
assure you it is a correct and accurate movement.
(Try it with chasecam off.)
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.
Since PA_JUMP is used to determine when
springing upwards now and the nextstate
isn't used for falling, the jump state
can now be properly animated. :)
Added drowning to all players, and several new
Super animations for Sonic.
Removed A_Fall from S_PLAY_DEAD and moved its
effect into P_KillMobj for player avatars.
No longer turns you super, instead emeralds steal points
from enemy players and give you (and relevant teammates)
an invincibility + super sneakers monitor.
P_PlayerWeaponPanelOrAmmoBurst will go through all of the
player's weapon rings and either drop the weapon panel itself
(with no ammo attached, and no ammo taken away!) OR if the
player has ammo but no weapon, it drops the ammo instead
(and you lose it).
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.
tmthing must not be set outside of P_MapStart and P_MapEnd
or the game will fail a sanity check which ensures that
mobj references are not persistent across frames and crash.
Angles now go from 0 to 0xFFFF (360 degrees == FRACUNIT) instead
of using a full UINT32. Lua only has one number type, so signedness
gets in the way of using angle_t directly. This handling of angles
matches up with how ZDoom ACS scripting and the like does it.
I also changed all the integer casts and pushes of fixed_t to
their own macro in preperation for possible future seperation.
EvalMath is for SOC only.
It spawns an entirely seperate instance of Lua and requires
uppercase-only strings, and it's ability to parse strings to
enums is redundant to Lua's _G table (try using
_G["MT_BLUECRAWLA"] for instance)
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?
Actual blockmap fix
MI's "fix" was a reversion of something that allowed 2.0 maps to use the entire blockmap. This MR reverts that fix and adds a proper fix to the issue of west/south edges of the blockmap not working as they should. Tested with a thokbarrier-less square map (all sides were solid) and with AGZ (objects are tangible all around the map, like they are in 2.1.14).
See merge request !10
Re-fix the server global variable in Lua
I screwed up the conditions on my first attempt to fix this, since I only tested one scenario. Tested this in SP, at the main menu, and both clientside and (dedicated)serverside in MP. Everything works as intended.
See merge request !9
Polyobject more fixes
Extra fixes related to polyobjects; actually properly putting their flats alongside them in the draw list, and making them able to use single-waypoint zoom tube sequences. Also threw in a smoothness fix for swinging chains while I was there.
See merge request !8
Polyobject scroll hotfix
Things fixed:
* Polyobjects should now carry the same thing types as conveyors (notable example; they'll now carry Crawlas when they wouldn't before)
* The drifting issue with players on spinning polyobjects should be fixed. (I swapped in the old bad hack for a new hack that should work like it's supposed to)
See merge request !6
Now it will only bounce ONCE when you jump on it, and Knuckles
just barely gets enough velocity out of his jump for even that.
This will leave players vulnerable and annoyed for a lot less
time while they wait to finish bouncing.
...
(It's that infamous intangible West/South linedefs bug, which was really a blockmap-related bug all along. AND IT WAS SO SIMPLE TO FIX!)
git-svn-id: https://code.orospakr.ca/svn/srb2/trunk@9048 6de4a73c-47e2-0310-b8c1-93d6ecd3f8cd
Core code has too many #define dependencies on interface-specific
defines. This means that it's currently not possible to safely
separate the core and interface code into different contexts. The
core code should be refactored to accomadate for this because we
should not have any interface-specific code in core in the first
place.
This reverts the static library SRB2Core from a7135094 and instead
adds the core sources to the SRB2SDL2 target directly.
So frustrating...
Core and SDL2 are two separate targets now. Core is a static library
that is linked into SRB2SDL2. The sources for both are separated.
When using an IDE like Visual Studio or Xcode, the source code
organized into groups that explain what that group of sources does.
In the future, "Main" could be split into a few more groups based on
file prefixes, but I think the way it is set up works for now.
Makefile targets are not affected by source_groups and typing `make`
will automatically compile both the "Core" library and SRB2SDL2
itself.
Access the benefits of -debug, console devmode, and a complete gamedata.dat (all secrets unlocked) all in one go.
Moved "#if 0" and "#if 1" to "#ifdef DEVMODE" so the existance of this cheat and MD5 validation and all that can be toggled in one place too.
git-svn-id: https://code.orospakr.ca/svn/srb2/trunk@8998 6de4a73c-47e2-0310-b8c1-93d6ecd3f8cd
Todo: Stop the redundancy that currently goes on with adding MD2s on game start-up (note that HWR_AddSpriteMD2/HWR_AddPlayerMD2 are run for all sprites/skins BEFORE HWR_InitMD2 is called)
git-svn-id: https://code.orospakr.ca/svn/srb2/trunk@8988 6de4a73c-47e2-0310-b8c1-93d6ecd3f8cd
...
(It's that infamous intangible West/South linedefs bug, which was really a blockmap-related bug all along. AND IT WAS SO SIMPLE TO FIX!)
git-svn-id: https://code.orospakr.ca/svn/srb2/trunk@9048 6de4a73c-47e2-0310-b8c1-93d6ecd3f8cd
Currently the main benefit of these changes is that a number of non-Object-related hazards/deaths no long rely on dummy MT_NULL objects or other hacks to tell the game how you were hurt/killed, yay
git-svn-id: https://code.orospakr.ca/svn/srb2/trunk@9039 6de4a73c-47e2-0310-b8c1-93d6ecd3f8cd
running is another story
Author: Ronald Kinard <furyhunter600@gmail.com>
Date: Wed Jan 28 02:09:03 2015 -0600
git-svn-id: https://code.orospakr.ca/svn/srb2/trunk@9013 6de4a73c-47e2-0310-b8c1-93d6ecd3f8cd
Find them in MAINCFG in player.dta instead, where they belong. This means that player.dta finally contains ALL playable character-related data, with none of it in the iwad or exe.
git-svn-id: https://code.orospakr.ca/svn/srb2/trunk@9003 6de4a73c-47e2-0310-b8c1-93d6ecd3f8cd
Access the benefits of -debug, console devmode, and a complete gamedata.dat (all secrets unlocked) all in one go.
Moved "#if 0" and "#if 1" to "#ifdef DEVMODE" so the existance of this cheat and MD5 validation and all that can be toggled in one place too.
git-svn-id: https://code.orospakr.ca/svn/srb2/trunk@8998 6de4a73c-47e2-0310-b8c1-93d6ecd3f8cd
