It turns out the particle preloading fix revealed a long standing bug in the particle `pageIn()` function--it should be calling `bm_page_in_texture()` instead of `bm_page_in_aabitmap()`. It's been wrong the entire time and we didn't notice because of the frame bug, which was fixed in #3884. Without this fix, when it's preloaded it locks the image as 8-bit, when it force loads it's 24-bit. Tested and works as expected.
Fixes#3890.
Massive thanks to taylor for spotting this!
Previously the `bm_page_in_aabitmap` call in `ParticleProperties::pageIn()` used -1 as the number of frames. It seemed particles with more than 1 frame still worked correctly, but likely prevent preloading of particles. This PR fixes that to use the actual number of frames.
This system adds the code necessary for letting content creators specify
complex events by specifying a simple, program-like sequence of
operations that will be executed by the engine when a certain event is
triggered.
In the particle effect code there is a small hack required for getting
some constant pointers in a vector. However, there is another mechanism
where sources are not added to the sources vector if the sources are
currently being iterated through. That is necessary to avoid
accidentally invalidating the iterators.
The issue here was that the vector resizing hack was not applied to the
correct vector when we were currently iterating. This fixes that.
This fixes#2928.
There are some possibilities where we could get an expired pointer when
we create a persistent particle. This adds a check for that to avoid
crashing the engine in those case.
This is related to #2928.
This adds a mechanism for running generic operations at specific points
of the frame execution. This can be used by any part of the code an not
just Lua since it simply executes std::functions. It also adds an
"execution context" concept that specifies in which situation an
operation should be executed.
This is then used by the Lua Coroutines code for resuming coroutines at
specific points instead of always when the awaited promise resolves.
If anything less than or equal to 0 was specified it would trigger some
kind of an assert in the standard library since that is not a valid
value for a normal distribution. Now a parse warning is generated and a
safe default value is used.
This fixes#2269.
This allows specifying how many times per second an effect should be
triggered for a particle source instead of triggering the effect every
frame. This will allow modders to achieve more consistent particle
effects regardless of FPS.
This makes some general changes to the particle parsing code. It moves
the trail effect option to the end of the options list to remove an
ambiguity in the resulting parsing code. This is done in a backwards
compatible manner so existing tables will not be broken by this.
This also introduces support for specifying single number ranges
without the parentheses to make that easier to use.
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.
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 adds support for specifying multiple sounds for a single game sound
entry. The engine then selects which sound will be played based on the
strategy provided by the game data. This required a few changes to some
of the game code since previously every game sound had exactly one sound
file attached to it. The most notable change is that it is no longer
possible to determine the exact duration a sound can have so instead the
new code computes the maximum duration a sound can have and uses that
where appropriate.
This also adds support for randomizing the pitch and volume of the sound
to provide a more varied experience even if only a single sound is used.
One possible issue that exists is that the "sequential" strategy only
works globally at the moment so if two sources use the same game sound
concurrently then the two sources will share the sequence of sounds
since there is no sound instance data at the moment. That can be added
in a future change but should not present a huge issue for most
use-cases.
Visual Studio on Appveyor somehow causes deprecation error on _our_
definition of vsprintf. I have no idea why these changes introduced this
warning but I won't debug Visual Studio compiler bugs that I can't
reproduce with my Visual Studio version so I just disabled those
warnings.
Previously, the source orientation was always aligned to the world so it
couldn't adapt to a weapon that changes direction. This fixes that by
introducing a "relative" mode for source orientations that is enabled by
default and disabled if the direction is set explicitly.
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.
David Gibson