I also fixed a few issues where the internal char array was used as a
mutable string which changed the string after it was parsed which is not
good(TM).
This also replaces all user-facing occurences of usages of name to use
the new function so that the correct, possibly translated, name is displayed
to the user.
This adds a new class which allows to create type safe resource handle
types. At the moment, the engine uses ints pretty much everywhere for
providing handles to resources created by the specific subsystems. Since
all ints are the same to the C/C++ typesystem it is perfectly legal to
pass a sound handle to the graphics API as a buffer handle which will
obviously cause issues.
This adds a new type called "ID" which is a wrapper class for a generic
handle but with added type safety. An instance of this class cannot be
passed to a function expecting another type of handle which provided
compile-time type safety for these APIs.
As an initial test I converted the game sound handles to this new type.
I already found a bug in the mainhall system thanks to this new type.
The mainhall used the game sound handles as sound instance handles which
probably meant that that specific code never really worked right. I
removed the code since there was no better alternative for fixing it.
The current particle system uses dynamic allocation of particle
instances for keeping track of particle instances. This adds unnecessary
overhead in case the code does not need a handle to this particle which
is the case in pretty much all instances.
The new non-persistent particles are stored in a standard vector without
dynamic allocation which should make the processing steps using this
vector much faster and allow better scalability in case more particles
are used by a mission.
This allows to render screen space decals into the deferred lighting
buffers no matter how complex the underlying geometry is.
Currently there is only limited support for using this in the engine.
Only weapon impact decals are supported at the moment for testing
purposes.
This caused a warning in GCC7 which is fixed by this. This will also
initialize the array properly since the previous version may not have
worked correctly even if the entire array woudld have been written (on
all supported platform it would have worked since repeating -1 on all 4
bytes of an int will still produce -1).
Shield impact sounds now re-use the shield quadrant calculated by the collision code instead of naively recalculating based on global hitpos, allowing the hull impact sound to play if the shot pierces shields or was fired from within the shield mesh, and simplifying the relevant calculations in the process.
Adds a new "+Pulse Interval:" countermeasure field that enables the new behavior; all countermeasures that don't have this field defined still use the old behavior of the global frame counter.
This changes countermeasure logic quite a bit, but I attempted to mitigate performance implications by re-using an existing traversal of the object list in order to build the list of active countermeasures each frame. If any countermeasures are actively pulsing in a frame, the object list is traversed again, looking for homing weapons. Each homing weapon then goes through the active countermeasure list and checks to see if it got decoyed. Most of this central logic is unchanged from the old behavior, although no longer separated into two functions, and it should be more efficient since it's using a prepared list of active countermeasures instead of traversing the object list looking for countermeasures for every homing missile (which are themselves found by traversing the object list).
This makes it easier to determine what takes the most time while loading
the mission (loading models) and how we could optimize that load time
(optimize model loading).
This is not a bug fix but it also shouldn't cause any regressions since
there are no actual code changes so this could be merged before the
release of 3.8.
If the descripting of a weapon is too long it would currently cause a
very unhelpful assertion message. This fixes that by checking the length
of the lines when parsing the weapon description. I removed the
assertions since the string is just cut of if it is too long so that
fixes the actual assertion.
I also added two unit tests for making sure that too long descriptions
cause warnings.
THe flagset changes misplaced the post-parsing flag processing so that
it was only executed if a special flag was found. That was not the case
previously and this restores that behavior. I also simplified the code a
bit while I was at it.
This fixes#1191.
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).
asarium