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.
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.
Asteroth