This advances the versions for Clang to 16 and GCC to 13 along with
fixing any warnings these new versions are detecting now.
The new image versions also include Vulkan so the additional workflow
step for installing that is not necessary anymore.
* proof of concept
* Account for shadows
* Option to tie individual HUD gauges to the cockpit option
* Do this in a more user-friendly way
* Address feedback
Allow different types of cargo scans, including the -dualscanline behavior, to be specified in the HUD gauges table. Right now the options are "default" and "dualscanlines".
FRED needs to work with any HUD gauge in the table, so don't prune any based on resolution. Fixes#4517.
This also improves checking for duplicate names in the FRED gauge list.
* Add New Options to Wingmen Gauge
This PR adds two new options for modders to use in the HUD table for the wingmen gauge:
1) `Use Full Wing Names:` which draws the full wing name and does not alter the capitalization.
2) `Use Expanded Colors:` which use red, yellow, or green color to designate wingmen health (green 1.0 to > 2/3, yellow 2/3 to > 1/3, and red <= 1/3.
Also adds the bright red option to dead wingmen, which seems like it was missing before(?).
Tested and everything works as expected.
* correct string copy length
* fix out of scope case variable
Consolidate all the functions which parse lists of data. They're almost the same except for the data itself, so use templates.
As for the templated function which handles the list, boost the robustness by adding additional checking and error messages.
The multilock patch did not handle `Lock_anim` in the best way, and handled `Lock_gauge` in a very bizarre way, despite the fact that they are two simple hud animations. This changes the `lock_info` struct to track the correct `time_elapsed` value for both, and changes the locking code to use the values in the correct way.
Additionally, this properly loops the lock triangles on the FS1 lock indicator. Strangely, even prior to the multilock merge it appears that the triangles wouldn't have animated more than a quarter turn.
Finally, this prevents the FS1 lock indicator from blinking, since in retail FS1 it didn't blink.
Tested with FSPort and no-mods. Fixes#2826.
Admiral Nelson led me to discover that the HUD gauges expected "right" or no string at all for the gauge alignment. I added basic recognition of LEFT and RIGHT alignment. Someone more familiar with the HUD than me can flesh it out more.
1) Upgrade the pilot file code to correctly save flags whether entries are added *or* removed
2) Make the tech-db/tech-db-multi ship flag handling consistent
3) Add scripting support for intel entries
4) Add scripting support for adding and removing entries from the tech room
5) Minor cleanup
We didn't realize that Gauge_load_common had some assumptions about where Origin: and Offset: are, so we accidentally broke custom radars. Moving this section up forces modders to have an odd order for their entries, but based on the way the code was written, there really doesn't seem to be another choice.
Unique pointers need to be constructed in very particular ways, but so did this NGON radar class, so we just had to put the constructor function inside unique pointer constructor.
And to keep that special pointer from going out of scope, we switched to the ternery operator.
Also made these changes:
Change to hypotf()
Fix Shadowing, Zero Vector macro not working at all.
Offset changed to offset_incoming
blip changed to blip_instance
Offset changed to = {} to initialize the struct without a problem.
clampBlip() required an override
Give offset a default initializer.
Switch to <cmath>
(Apparently <math.h> was deprecated and needs to be replaced with <cmath>.)
One last complaint from travis about a redundant default value.
Thank you Travis!
* Modders can specify how many sides the radar can have (as few as 3) with "Ngon Sides:" and can also define an optional twist angle with "Ngon Offset:".
* Also refactors the standard radar code a bit
The new gauge can be accessed by the scripting API with which a function
can be set which will be called when this gauge is rendered. This can be
used for exposing the HUD gauge positioning and RTT options to the
scripting API without a lot of work needed for the script writer.
There is currently only one rendering function implemented since this is
only a proof of concept.
Currently, the player is unable to see a RTT hud gauge if in chase view. This adds an option in the hud_gauges.tbl that tells the game whether to draw a gauge based on if chase view is the active view. So for example, a modder using RTT mapped gauges can now make a HUD that displays on the interior of the ship (ie RTT with the cockpit model) and a HUD that displays when the player switches to chase view.
Optionally play a sound when autoaim becomes active, and another sound
when autoaim becomes inactive
Credit to zookeeper - I'm just pushing this into master!
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.
Also added the "Center Text On Gauge X-Position:" option for the Fixed Messages gauge, which by default is enabled only if the gauge's position is not overridden.
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).
Previously the code simply skipped the invalid tokens and silently
ignored them. This is frustrating for modders and also let #758 slip
into the code base which would not have happened otherwise.
This allows to use standard TrueType Fonts for text rendering in FSO. It uses the NanoVG library which provides the ability of drawing 2D shapes. This library is used for most 2D operations now and can also be used directly by using the PathRenderer class.
BMagnu