cam_turnmultiplier and cam2_turnmultiplier.
"Camera Speed" has been renamed to "Camera Spacial Speed" in the menu. "Camera
Turning Speed" is now an option.
Reasoning:
* They're horribly broken (they completely ignore slopes).
* A similar final demo GL-only feature (coronas) has been completely disabled.
* Nobody's going to bugfix them before release because not even the devteam's resident GL users use them.
* They look ugly.
* Like Kart, remove cv_precipdensity.
* Like Kart, replace "Infinite" draw distance value with "None".
* Better thinker with more return optimisation.
* Better placement of thinking in rendering, to avoid ceiling-mounted sprite glitches.
Vissprites are now only clipped against their respective portal's geometry obtained from their BSP run.
Additionally, if a portal is provided, they're clipped to the portal's clip boundaries.
The work on this branch should conclude after a pair of remaining glitches are fixed.
The drawnodes are now fully grouped in separate lists, and then sorted individually. This fixes sorting problems caused by portals belonging to differently perceived scales (skyboxes for example).
Drawsegs and vissprite/drawnode sorting require the viewz, so the viewz is stored for each portal/view, and then restored when needed; without this, the rendering process erroneously sorts the elements, and draws some at wrong positions.
Each shall eventually have its specific vissprites/drawsegs; currently only drawsegs are stored in their correct list, vissprites are stored in the first list as a placeholder.
The idea is to sort each list individually, and then render their masked elements, starting from the last drawnode list.
This retains a non-recursive function calling method while still rendering things in order.
It seems to screw up the portal rendering in odd ways if it's in the wrong position. I apologize for not even knowing what it's meant to do nor how it works.
The skybox rendering process has been replaced with portals instead. Those are generated after the first BSP tree pass by looking for existing sky visplanes at the time, and their windows are used to define new portals.
The skybox portals are still incomplete and cause visual glitches when masked elements are involved.
Split portal-related code to its own source files.
Most of the 2-line-specific setup has been moved to the function which adds a 2-line case. The portals should render as they used to so far, anyway.
No longer using byte2float in DrawPolygon -- use the surface color data directly
Vertex Buffer Objects for non-interpolated model frames
Removed some old unused paletted texture stuff
"movebob" lets you determine the strength of movement bobbing (does not
affect landing delta, that's technically not movement bobbing :p),
values range from 0.0 to 4.0. viewheight is now relative to
player->height.
This means setting the skybox view angle is no longer stupid, objectplace no longer breaks skyboxes, and Lua-defined skybox mobjs can actually set a Z position more easily now.
MI's unimportant code cleanup
Just removing a bunch of unused variables/function prototypes from the source code and similarly minor stuff, nothing here should change gameplay much (if at all).
See merge request !71
* PF_NIGHTSMODE is now CR_NIGHTSMODE as part of player->powers[pw_carry]. This is because it's mutually exclusive to every other "carry" type.
* PF_SUPERREADY is dead because it literally just checked for all 7 emeralds and 50 rings. That's it. You couldn't even appreciably alter its presence with Lua. That logic has been placed back in P_SuperReady.
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
Also, the "teleport" devmode command can now gracefully handle coordinates specified outside maps with no/few thok barriers, which previously prevented teleport via the thok barrier bleed's sector floor and ceiling being equal.
To understand: look at AjustSegs(void) in hw_bsp.c. It reallocates the vetex_t pointers for lines as POLYVERTEX_T pointers, and of COURSE things are gonna get wacky when you're casting pointers.
I dunno how resilient the FLOAT_TO_FIXED solution is or whether it'll be netgame compatible (yayyy float precision loss) but it's not like our builds are netgame compatible with themselves
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
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
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.)
