init_player_stats_new_ship used select_primary_weapon and
select_secondary_weapon to assign the player's weapons. However, those
functions read the current weapon and jumped according to its value. A
new ship has no defined value for current weapons, so the jump triggered
an uninitialized value warning from Valgrind.
Add new functions set_primary_weapon, set_secondary_weapon that work
like the previous select_* functions, but always take the path used
for weapons not equal, without checking. This prevents the warnings
from Valgrind, as well as a theoretical risk of initializing the ship
improperly.
The declaration of valptridx_specialized_types needed to be found by
Argument Dependent Lookup, but this was inconvenient for some types.
Split the declaration of valptridx_specialized_types out from the
definition of valptridx global subtype.
Past releases, when rendering an invalid primary texture, would
Int3() and then reset the texture to zero. Commit d767f7c changed the
logic to return without resetting the texture, since the reset seemed to
be unnecessary. Unfortunately, it is necessary. Some levels, including
those shipped with the retail game data, specify bogus primary textures
on some surfaces. After d767f7c, rendering a surface with an invalid
primary texture causes the surface to be invisible, even if it has a
valid secondary texture.
Remove the return statement added in d767f7c. Extend
validate_segment_side to validate the primary texture on the tested
side. When an invalid texture is found, reset it and log a diagnostic.
For built-in levels, log at level CON_VERBOSE since players cannot
readily fix the level. For external levels, log at level CON_URGENT so
that level authors know to fix their level before releasing it.
Fixes: d767f7cd5e ("Pass vcsegptridx to render_face")
Headers included by SConstruct tests cannot rely on the existence of
"dxxsconf.h"; instead, SConstruct must define the symbols that would
have been in it.
Previously:
constexpr vTYPEptr{};
constexpr vcTYPEptr{};
Now:
__attribute_unused static vTYPEptr{};
constexpr vcTYPEptr{}; // unchanged from above
This is necessary for future work. It should have no user observable
effects for now.
Use a compound statement to cache the success condition as a local
boolean, then reference the local in the macro expansions. This should
hint to the optimizer that this is always the same expression, which
should encourage it not to repeat the test in the generated code.
Actual results vary. x86_64-pc-linux-gnu-g++-5.4.0 generates code that
is bigger, but uses fewer instructions.
