Previously, valptridx used PREFIX for allow-invalid+mutable, c#PREFIX
for allow-invalid+const, v#PREFIX for require-valid+mutable, vc#PREFIX
for require-valid+const. Convert the types, factories, and all usage
sites to specify a qualifier for all four combinations:
im#PREFIX -> allow-invalid+mutable
ic#PREFIX -> allow-invalid+const
vm#PREFIX -> require-valid+mutable
vc#PREFIX -> require-valid+const
Changes to common/include/valptridx.h and common/include/fwd-valptridx.h
are manual. All other changes are generated by:
git grep -lz -e '\(obj\|seg\|clwall\|wall\|actdoor\|trg\)\(ptridx\|ptr\|idx\)\(_t\)\?\>' | xargs -0 sed -i -e 's/\<\(v\?\)\(\(obj\|seg\|clwall\|wall\|actdoor\|trg\)\(ptridx\|ptr\|idx\)\(_t\)\?\)\>/\1m\2/g'
for the 'm' prefix and:
git grep -lz -e '\(obj\|seg\|clwall\|wall\|actdoor\|trg\)\(ptridx\|ptr\|idx\)\(_t\)\?\>' | xargs -0 sed -i -e 's/\<\([cm]\(obj\|seg\|clwall\|wall\|actdoor\|trg\)\(ptridx\|ptr\|idx\)\(_t\)\?\)\>/i&/g'
for the 'i' prefix.
For switch cases where existing comments or code flow logic obviously
intended to fall through, add a gcc-7 /*-fallthrough*/ comment to
silence warnings about this. Some cases which are less obvious are not
converted, so the code does not yet compile clean with
-Wimplicit-fallthrough.
Reported-by: parkerlreed <https://github.com/dxx-rebirth/dxx-rebirth/issues/338>
Kreator reported an uninitialized value crash when robots fired homing
weapons. No path assigned a value for track_goal, so it had a default
value of 0 (non-poison builds) or 0xfdfd (poison builds). Assign it a
value of object_none when the created weapon is a homing weapon. Leave
it unassigned for non-homing weapons, since those should never examine
track_goal.
Reported-by: kreatordxx <https://github.com/dxx-rebirth/dxx-rebirth/issues/274>
This fixes two problems on systems where sizeof(int) < sizeof(fix64)
(which applies on most systems).
Normally, the omega cannon does not charge for ~1/3 of a
second after firing stops.
The first problem is that, if (Last_omega_fire_time + 1/3 second)
exceeds 0x80000000 (about 9.1 hours), truncation issues confuse this
rule into not applying, thus allowing the omega cannon to charge
whenever energy is available, even while firing.
The second problem is that, if GameTime64 exceeds 0x8000000000000000
(about 4459701.8 years), a sanity check that attempted to compensate for
the incorrect tracking of Last_omega_fire_time would confuse the
recharge rule into deciding that the user had always fired recently,
which would prevent the omega cannon from ever recharging. The sanity
check would reset Last_omega_fire_time when Last_omega_fire_time was in
the future relative to GameTime64. Unfortunately, Last_omega_fire_time
was only an int, so the reset truncates off the high bits of GameTime64.
This truncation is harmless when GameTime64 is less than 0x80000000,
causes the first problem when GameTime64 is not less than 0x80000000,
but is positive, and causes the second problem when GameTime64 is
negative.
These problems were mitigated in prior releases by three factors. First,
a hack resets GameTime64 when restoring from a saved game, so the
affected game needs to run for ~9.1 hours (or ~4459701.8 years) without
reloading. Second, starting a new level resets GameTime64, so the game
needs to stay on a single level for ~9.1 hours (or ~4459701.8 years).
Third, the omega cannon discharges faster than it can recharge, so even
when the first bug allowed it to charge while firing, a player could
still drain Omega_charge to zero by continuous firing. However, it
would take longer to drain due to the bug-induced concurrent recharge,
and would not be subject to the 1/3 second wait normally imposed between
depleting Omega_charge and recharge beginning.
Fix these problems by replacing Last_omega_fire_time with
Omega_recharge_delay, which is 0 when recharging is allowed or a
positive amount of frame time if recharging is disallowed due to recent
firing. Set Omega_recharge_delay to 1/3 second when the user fires.
Decrease it by up to FrameTime when omega_recharge_frame runs.
This does not fix the preexisting problem that reloading a savegame does
not update the recharge delay, which manifests two related problems.
First, firing the omega cannon and then loading a game will bring the
delay through into the save, whether or not the user had been firing
just before saving. Second, not firing the omega cannon and then
loading a game will allow the user to fire immediately on load, even if
the user had been firing when the game was saved. Future work can
address the first problem by clearing the delay, but a savegame file
modification is required to address the second problem.
------------->8-------------
#include <cstdio>
int last_fire;
long t64;
/* The test program only shows the bug on 64-bit systems */
static_assert(sizeof(last_fire) == 4, "sizeof(int) != 4");
static_assert(sizeof(t64) == 8, "sizeof(long) != 8");
void frame(bool expect_recharge, const unsigned line)
/* clang does not support __builtin_LINE, so fake it with a macro
*/
#define frame(E) frame(E, __LINE__)
{
if (last_fire > t64)
{
printf(__FILE__ ":%u:%u: last_fire=%8x t64=%16lx: last_fire > t64, resetting\n", __LINE__, line, last_fire, t64);
last_fire = t64;
}
const int time_bias = 0x5555;
if (last_fire + time_bias > t64)
{
printf(__FILE__ ":%u:%u: %5sexpect_recharge=%i last_fire=%8x t64=%16lx: last_fire recent (%16lx), refusing to recharge\n", __LINE__, line, expect_recharge ? "BUG: " : "", expect_recharge, last_fire, t64, static_cast<long>(last_fire + time_bias));
return;
}
printf(__FILE__ ":%u:%u: %5sexpect_recharge=%i last_fire=%8x t64=%16lx: last_fire old (%16lx), recharging\n", __LINE__, line, expect_recharge ? "" : "BUG: ", expect_recharge, last_fire, t64, static_cast<long>(last_fire + time_bias));
}
int main(int, char **)
{
frame(false);
t64 = 0x7fff;
frame(true);
last_fire = t64 - 4;
frame(false);
t64 = 0x7fffaaab;
frame(true);
last_fire = t64;
++t64;
frame(false);
t64 = 0x7ffffffffd;
frame(true);
last_fire = t64;
++t64;
frame(false);
t64 += 0x10000;
frame(true);
t64 = 0x7fffffffffffff00;
frame(true);
last_fire = t64;
frame(false);
t64 = 0x8000000000000000;
frame(true);
t64 += 0x800000000;
frame(true);
}
Previously, do_laser_firing_player would update Next_laser_firing_time,
then do_omega_stuff would update it again. OMEGA_BASE_TIME is smaller
than Weapon_info[OMEGA_ID].fire_wait, so the first store was overridden
by the second. As a quirk, the override was skipped if the omega cannon
was unable to fire due to object limits or due to insufficient energy,
causing those rare cases to use the longer
Weapon_info[OMEGA_ID].fire_wait delay.
Fold the omega cannon handling of Next_laser_firing_time into
do_laser_firing_player to eliminate that quirk, simplify the code, and
remove the need to recompute fire_frame_overhead from
Last_omega_fire_time.
Constructing valptridx::basic_ptr with a known-invalid magic index does
not require an array. Simplify the static_assert to reject uses of
factory functions with known-invalid magic index values. Fix the two
sites that fail with the stricter static_assert.
gcc generates better code for:
if (variable == magic_constant)
return magic_constant;
than it does for:
if (variable == magic_constant)
return variable;
even though the two have the same result. Switch to the form which
generates slightly better code.
It was a convenient transition macro, but its presence was always
intended to be temporary. Expand it to ease the conversion of usage
sites that already have access to local player data through a local
variable.
It was a convenient transition macro, but its presence was always
intended to be temporary. Expand it to ease the conversion of usage
sites that already have access to local player data through a local
variable.
It was a convenient transition macro, but its presence was always
intended to be temporary. Expand it to ease the conversion of usage
sites that already have access to local player data through a local
variable.
Per comment, MK meant for this test to match the Helix cannon, but the
implementation was wrong. Primary weapon indexes cannot be compared to
weapon ID types. The two use different number spaces. Using proper
enum types for each causes the compiler to report this mistake. Fix the
test.
