This adds a mission file option for ships which allows specifying a
different string which should be used for displaying the name of the
ship to the user. This name will not be used in SEXPs or other ship
lookup functions so it can be freely translated and two ships can also
have the same display name.
The new feature can be used by adding $Display name: <string> after $Name
for a ship in a mission file. I think I added proper support for FRED
(and qtFRED) so that this new value is properly saved but it would be
great if someone could test that.
This implements one of the features requested in #1730.
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.
This converts the previous int handles to a strongly-typed wrapper
handle which will make the API more self-documenting and will ensure
that wrongly used handles are detected at compile time.
I already found a few mistakes with these changes which I also fixed
here.
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.
This fixes various issues I found while trying to compile FSO in a cross
compilation setup using MinGW. This is a prerequisite for merging Tea-CI
support.
FSO now allows the window title to be specified via game_settings.tbl, some never-used function arguments were pruned at the same time, and fred.rc now receives version information (for the About dialogue and the title bar) from a cmake-generated header, so the version numbers get filled in properly. Speaking of FRED's About dialogue, it now displays the copyright symbol properly.
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.
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.
I split this from #1331 to make reviewing these two changesets easier.
These changes convert all usages of const char* to SCP_string in the
static SEXP arrays so that the dynamic SEXP system can use SCP_strings
instead of having to allocate the strings and then somehow figure out
which strings must be freed at the end of the program.
This also converts the SEXP arrays to vectors so that new SEXP operators
can be added at runtime later.
This renames the functions exposed by flagset so that it's clear that
64-bit values are returned. This also cleans up usages of wrong format
specified when that value is printed which caused some issues in the
past.
This should also fix#1336.
Goober5000