Although normalized vectors in FSO are supposed to stay normalized, occasionally small floating point errors can pop up. In most cases these do not cause a problem, but in certain cases these errors can rapidly accumulate and corrupt an otherwise well-behaved matrix. This can most easily be seen with daisy-chained dock sequences or docked ships with angled dockpoints.
This PR audits the usage of `vm_vector_2_matrix_norm` to re-normalize vectors in cases where floating point errors could accumulate. There are also a few new Assertions for extra vigilance.
Follow-up to #6596. Fixes#6634.
Most places in the code that use `vm_vector_2_matrix` do so on already-normalized vectors. Changing these to `vm_vector_2_matrix_norm` avoids redundant normalization.
Fix the inadvertent swapping of the two utility functions for parsing sounds. While we're at it, streamline a few lines, remove a few C-style casts, and remove an unused function prototype.
Follow-up to #6314. Fixes a crash encountered by Inferno on 24.2-RC1.
According to DahBlount:
> Most atan2 implementations for a long time had problems when the inputs were close to machine epsilon or when x was less than or equal to 0
And according to z64555:
> Modern versions of C++ should have an atan2() that works correctly when the inputs are at 0 or near epsilon of the floating point specification, meaning Volition's workaround shouldn't be needed anymore.
So this removes `atan2_safe` and changes all instances to `atan2`. Consequently, the angle range in FRED now shows as [-180, 180] as expected.
Fixes#3730.
* coverity - using `std::move` instead of copying, and change some parameters from value to reference
* coverity - fix or mark potential copy-paste mistakes
* coverity - various checking of parameter and return values
* coverity - miscellaneous fixes, and change some 'intentional' markers to 'false positive' markers
I took a close look at the code involved in parsing particle tables. There is no smoking gun, but there are several ways to polish the code which I have implemented here. The most likely culprits for the slowdown, IMO, are the repeated conversions between SCP_string and C-string, especially in `ParticleManager::getEffectByName()`; followed by the omission of `std::move` in several places.
* Remove old interpolate angles quick
* Remove old interpolate functions
These are no longer used.
* Add linear interpolate vm function
More clearing functions
* Add physics snapshot struct to silo interpolation
Two of these two functions require an object pointer, so they cannot be in physics_state.cpp
With doxygen documentation
* Try to placate Linux
* Address Feedback
* And update declaration, of course
* Attempt to appease linter
Change the casts used in the convenience #defines in floating.h. Since these #defines are used pretty widely, this should reduce the count of C-style casts in the codebase by quite a bit.
Also change the casts in floating.cpp while we're at it, and remove some obsolete or unused code.
This adds a new field to particle effects so that particle rotation can be configured on a per-type basis, not just on a blanket basis. Implements #5941.
The ai-fly-to-ship goal was added early in FSO's development but never worked right. Until recently it could crash; and even aside from the crash the AI would try to reach the target's exact position, causing repeated collisions. This folds ai-fly-to-ship into ai-stay-near-ship, since the behaviors are conceptually the same except for fly-to being satisfied as soon as the target is in range.
This also adds a new "escort" mode usable by both behaviors. The default Volition behavior is to swoop toward the target in a long, graceful arc; the new mode generates a goal point and flies directly to that point. These can be toggled via an optional sexp parameter.
There is also some minor cleanup and a new vec3d operator for convenience.
Needed for Scroll; depends on #5667.
See title. There were some cascade effects, but the changes are mostly contained to the model code. The calls to `gr_render_model` and `g3_render_primitives` use `const_cast` because constifying that API would require a whole other PR.
The `SCP_string_lcase_equal_to()()` and `SCP_string_lcase_less_than()()` functors are rather unwieldy to use in non-functor situations, so this adds conventional function equivalents.
Adds gravity! Applies on a per-mission basis, and weapons, ships, debris, and asteroids now have a configurable "gravity const" which multiplies the effect of gravity on them, by default everything except debris is 0 (meaning no effect even when the mission has gravity). AI and the lead indicator will also lead for ballistic trajectories as well, given a gravity-affected weapon. No FRED support or gravity direction control yet, to come in later PRs.
Written by Asteroth, derived from our ai code. I added a couple safety checks and changed the type to void to match our library.
Co-Authored-By: Asteroth <[email protected]>
Floating-point comparisons are tricky beasts. See this article for a good summary of the issues involved:
https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
This PR improves support somewhat, although there are obviously situations in the code (such as comparisons to 0) that should still be addressed. This PR makes the following improvements:
1) Tightens the threshold on `IS_VEC_NULL` and `IS_VEC_NULL_SQ_SAFE` from 1e-16 and 1e-36 to FLT_EPSILON
2) Tightens the threshold for parsing `turn_time` in POFs
3) Restores the previous implementation of `fl_equal`
4) Adds a dedicated `IS_MOI_VEC_NULL` for moment of inertia values
5) Improves documentation
Follow-up to #4535 and #4443.
BMagnu