This maintains the type information which can be used for enforce
const-correctness and also for implementing more advanced ways of
handling the type information.
The routine ai_turn_towards_vector() had an unused parameter (frametime)
and it has been removed.
Each of the instances where this routine is called have also been updated
to reflect the parameter removal. As this resulted in the routine
swarm_update_direction() suddenly having an unused parameter, that routine
and the places where it is called have also been updated (remove
unused parameter).
Signed-off-by: Peter Mitsis <[email protected]>
This is similar to the other changes I already posted. Here the sound
instance handles are converted to their own handle type which will make
it easier to use the sound API.
Nightmare discovered an off-by-one error when checking the validity of a
particle effect handle. Since the new ID system makes that much easier
and less error-prone I decided to go ahead and convert all handles to
an ID typedef which also fixes the reported bug.
This can be used for mark parts of the code which should be unreachable
in normal execution. In debug mode, if such a statement is reached an
Error dialog is shown which aborts the execution. In release mode the
macro is replaced with a compiler specific expression that lets the
compiler know that this part is unreachable which allows it to optimize
the code better.
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).
*Homing conditions are now consistant with in-frame checks
*Swarm missiles will now only change their homing pos during a change frame. This'll reduce their hit rate if SWARM_FRAME_STOP_SWARMING is too low, but will make their pathing more cinematic.
The particle sources of the beams were missing multiple properties
(direction and impact normals) and the generic shape effect didn't have
any way of controlling how long the source was active. This fixes that
by introducing an effect timing field similar to the single particle
effect.
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.
Back when I added the "same emp time for capships" flag in SVN r9540, I neglected to multiply the EMP time by 1000, as the EMP disruption time for fighters is specified in seconds but the time for capships is specified in milliseconds. So, using this flag would cause capships to suffer EMP disruption for almost no time at all.
This PR fixes that, and also extends the explosion-effect sexp to specify this parameter. And I also cleaned up the fireball section by calling eval_num(n) just once instead of several times.
beam_pause_sounds() "pauses" looping beam sounds by setting their volume to 0; beam_unpause_sounds() "unpaused" by calling beam_recalc_sounds(), which only set the volume correctly when -no_3d_sound is set; 3D sound updates the sound's position without changing its volume. This PR just makes beam_unpause_sounds() perform the inverse operation of beam_pause_sounds() if 3D sounds are enabled.
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).
If framebuffer shockwaves were enabled and a 3D shockwave was created, FSO would use a hardcoded reference to the second slot of the Shockwave_info vector to generate the framebuffer shockwave for it. This only makes sense if and only if:
- the 3D shockwave command-line flag is also enabled
- the default 3D shockwave and default 2D shockwave are both present and loaded
- its the first mission of the session (because after that any shockwave not in the 0th index got unloaded)
I've changed the code so that which index the default 2D shockwave got loaded into gets tracked and used instead of a hardcoded index... and if both default shockwaves are loaded, the first two Shockwave_info indices are both kept between missions instead of just the first. This should allow framebuffer shockwaves to work with 3D shockwaves, regardless of whether or not it's the first mission of the session and whether or not a custom 2D shockwave was loaded (and happened to wind up at index 1). Slight downside in that missing the default 2D shockwave file, but having a custom 2D shockwave loaded, will now result in framebuffer shockwaves not being drawn at all, rather than using the custom 2D shockwave by accident; not sure that's really all that much of a problem, though.
asarium