Other notes:
* on second thought I'll keep the hw_clip functions' gld prefixes rather than HWR, not like it matters either way
* despite the extra lag it does fix the issues with translucent walls and such when displayed at different vertical angles, such as with the GFZ1 waterfall
Other notes:
* Renamed all new functions to have HWR_ prefix instead of gld_, for consistency
* HWR_FrustrumSetup and HWR_SphereInFrustum are disabled and require HAVE_SPHEREFRUSTRUM. This is because 1) SRB2CB did not need the code, so presumably neither will we, and 2) there are some OpenGL API functions used there that due to our way of using OpenGL we don't use outside of r_opengl.c, which makes dealing with HWR_FrustrumSetup complicated in theory
* The new clipping functions are not added to OpenGL's "main" rendering code itself just yet, they're just available to use now once hw_clip.h is included
Hardcoded VAda Flickies
Many thanks to MI for his help, even if he has sinful opinions on what the collection of creatures should be called. ;P
* Flickies are now handled via A_FlickySpawn instead of hardcoded in P_KillMobj, so there can be mobjtypes with MF_ENEMY which don't create flickies, or other mechanisms which can much easier.
* Added map header "FlickyList" (aka "AnimalList") parameter, which can either be set to:
* A species (eg: "Rabbit" or "Bluebird", amongst 17 currently supported types in dehacked.c table FLICKYTYPES - including the seed from Sonic CD, which isn't limited to 'soniccd on' in the console now)
* Any valid mobjtype that isn't MT_NULL (eg: "MT_FLICKY_GHOST")
* A comma-seperated list of either of the above, up to 64 entries long (eg: "Cow,MT_FLICKY_SPIDER,Chicken")
* "All" - sets behind-the-scenes stuff to use every 'normal' type of flicky in FLICKYTYPES (a distinction which can be utilised to hide secret level flickies where they wouldn't be appropriate for the main game)
* "Demo" - sets behind-the-scenes stuff to use the five flickies closest to the species used in the game's long history.
* "None" - prevents any flickies from spawning.
"Demo" is functionally the default value if you don't include a FlickyList parameter in the header at all.
Of note, a bunch of functions are now created:
* A_FlickySpawn - spawns flicky.
* A_FlickyAim - aims for area near target, but not directly on them - turns around when hitting wall
* A_FlickyFly - flies/swims around target (calls A_FlickyAim)
* A_FlickySoar - hacky alternate fly (calls A_FlickyAim)
* A_FlickyCoast - slowing down before going off again
* A_FlickyHop - fracunit-scale precision for A_BunnyHop
* A_FlickyFlounder - A_FlickyHop with randomisation
* A_FlickyCheck - State-setter for falling, or being on-ground
* A_FlickyHeightCheck - State-setter for falling, or being below a certain height relative to target
* A_FlickyFlutter - A_FlickyCheck, but with a slow fall/movement (calls A_FlickyCheck and A_FlickyAim)
I don't need to enumerate the object types and states that have been added, do I?
Oh yeah, I also made it so get_mobjtype's failure value was MT_NULL and prohibited SOC from editing the properties of it to compensate.
IN ADDITION: Killed "soniccd" console command, since it made things more complicated and honestly being able to specify Sonic CD seeds in the level header is a better option.
See merge request !60
Some texture-related fixes
Bugs fixed in this branch:
* upper/lower/middle textures with non-existent texture ids being capable of crashing the game. For instance, RVZ1 has colormap codes on non-colormap linedefs, which causes them to wind up with invalid texture ids because of how the game tries to interpret lower/upper textures with "#" followed by characters on normal linedefs. Fortunately these "textures" are normally not visible anyway (since they're all in control sectors) unless they are swapped with in-level textures by some crazy Lua script of some sort...
* animated single-patch textures with holes displaying garbage on first viewing (see this thread: https://mb.srb2.org/showthread.php?t=42195)
* the heights of the lighting (shadows or colormapping) from water/translucent/shadowcasting/etc FOFs become messed up when displayed on repeated midtextures.
See merge request !144
this fixes a crash in (old) GFZ2 at the ramp as a result of creating pv1/pv2. This probably means before pv1/pv2 there could have been some silly typecasting from vertex_t to polyvertex_t to get fixed vertex coords and such...
I added similar checks for the other num* but it seems some MD2s break the other limits without knowing anyway ...so I've commented these checks out for now, unless we have further discussion regarding them later on
Animated sky support
What it says on the tin: skies can be animated textures now. Just set them up as normal animated textures (keeping in mind the starting texture still has to comply with the SKYn/SKYnn/SKYnnn naming format) and hey presto, your sky animates.
See merge request !34
* flips the sprite ala MFE_VERTICALFLIP except you don't need to flip the direction of gravity for the object just to draw upside down
* stacks properly with reverse gravity
* 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.
* Several new supercolours.
- SKINCOLOR_SUPERSILVER1-5 (for fun) - "Silver"
- SKINCOLOR_SUPERPERIDOT1-5 (nyeheheh) - "Peridot"
- SKINCOLOR_SUPERCYAN1-5 (for fun) - "Cyan"
- SKINCOLOR_SUPERPURPLE1-5 (for fun) - "Purple"
- SKINCOLOR_SUPERRUST1-5 (mecha/metal sonic) - "Rust"
- SKINCOLOR_SUPERTAN1-5 (shadow/silver the hedgehog) - "Tan"
* SKINCOLOR_SUPER1-5 renamed to SKINCOLOR_SUPERGOLD1-5, one index for darkest is changed - "Gold"
* SKINCOLOR_TSUPER1-5 renamed to SKINCOLOR_SUPERORANGE1-5, ported properly to the new palette - "Orange"
* SKINCOLOR_KSUPER1-5 renamed to SKINCOLOR_SUPERRED1-5, ported properly to the new palette - "Red"
* new S_SKIN attribute - supercolor - uses an entirely different function to get the names (R_GetSuperColorByName instead of R_GetColorByName)
* a fun little secret - typing "god on" in the console whilst super makes the player hyper (visual only, no sparkles - just rainbow flash) - can be removed if no fun is allowed
* Electric sparks coming off entire body instead of bubbles coming out mouth
* Different sounds.
* Different icons.
These sprites are currently local only, but I'll be doing a lot of asset updating this evening since Rob asked me to so it won't be long until you can get them.
* NAMEcL refers to a frame which is seen for the entirety of an object's left side.
* NAMEcR refers to a name which is seen for the entirety of an object's right side.
* NAMEcLcR does both sides.
* Having just a NAMEcL requires you to fill in the opposite side either with NAMEcn where n is 1 and 5 to 8 OR fill in with a NAMEcR
* Switches down the centerline of the object instead of at the ANGLE_202h interval for normal sprites.
* Characters were selected for 1) ease of use 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
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
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
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.
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
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.
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
SPR_PLAY now calls up a secondary spritedef for all animations for all players. Old character wads (including player.dta) are no longer compatible.
git-svn-id: https://code.orospakr.ca/svn/srb2/trunk@8993 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
