Make sure we've got initialized values in the secondary pattern indexes
for a ship_weapon and also allow linked/dual fire to be in sequence
instead of swapping in the base weapon at the beginning of each pattern
loop.
The codebase had quite a few instances of .size() being called and then checked to see if it was 0 or not (or less than 1, or greater-than-or-equal-to 1, which are basically equivalent), when .empty() could be called instead (negated or not, depending on what the original condition was).
It was setting the Pierce_shields flag based on whether or not the Beam flag was set, rather than based on whether or not the beam flag was explicitly provided; as such, a TBM entry for a non-piercing beam that contained a "$Flags:" entry but didn't re-set "no pierce shields" could spontaneously regain its piercing status (explicitly setting "beam" again will re-add piercing, but this should match previous behavior).
Starting with git 127976c (#851), FSO fails to start, displaying an
error. This is my attempt to fix it. FSO starts, but I do not know how
to check that the flags are parsed correctly.
This introduces a new mechanism for handling bit flags. Instead of using an int (or two, or three) to write bits into, this uses the std::bitset in a wrapper class that accepts an enum class as input. This means that certain classes of errors we've had a few of in the engine, where a coder used the wrong set of flags or checked them against the wrong variable (SF_STEALTH vs SIF_STEALTH, for example) can now be detected at a compiler level rather than not at all.
Bombs can give points for being shot down. This was being handled by a full-blown pair of damage_ship/damage_ship_id arrays, just like ships have for scoring purposes. This is ridiculous overkill when most bombs are shot down with a single pull of the trigger and means we were storing a couple hundred bytes of data that would be completely unused for the vast majority of projectiles. Now, whoever shoots down a bomb gets the points for it; period. Simple, and we can remove all scoring data from the weapon struct.
This seems preferable to storing an entire mc_info object on every weapon, when the vast majority of projectiles (by the very nature of the fact that they still exist) won't have collided with anything.
On the other hand, I'm not wild about allocating and freeing memory every time a weapon collides with a ship or debris. If anyone has a better solution, I'm all ears.
Fix silly issue preventing getFrame() from working
Remove infinite loop when calculating frame num
Convert more animations to use new frame calc function
Replaces calls to double-precision floating point trig functions with
calls to single-precision floating point trig functions as follows:
cos() -> cosf()
sin() -> sinf()
tan() -> tanf()
acos() -> acosf()
asin() -> asinf()
atan() -> atanf()
This allows the compiler to avoid generating unnecessary instructions
that convert a float to a double and then a double back to a float.
Signed-off-by: Peter Mitsis <[email protected]>
Both the ANG_TO_RAD() and fl_radians() macros were serving the same
purpose; they converted an angle from degrees to radians. To reduce
code duplication, ANG_TO_RAD() was replaced with the existing
fl_radians().
Signed-off-by: Peter Mitsis <[email protected]>
This is a renaming of the Dumb_rotation infrastructure, which is now called Intrinsic_rotation. Intrinsic rotations are automatically applied to submodels without the need for an associated subsystem. Dumb rotations are now a type of intrinsic rotation, and look_at rotations will be added in a future PR. The same code will handle both; the only difference is in how the intrinsic rotation is calculated. (In the case of dumb-rotation, it is calculated the same way as normal rotation; in the case of look-at, it will be calculated using submodel_look_at.)
DahBlount