This field is used in the SDL build for rendering. In the GL build, its
only purpose is for the editor to write it to a PIG file. Change that
one use to compute the value as needed. Move all other references
behind a preprocessor test for !DXX_USE_OGL. This shrinks the size of
grs_bitmap by 1 pointer, since the compiler added padding after
avg_color up to the size of the next aligned pointer.
This adds a new dependency, but most systems likely already have
SDL_image installed. Use of SDL_image can be disabled, but this is
discouraged, because various in-game interfaces assume the use of the
original background.
The old implementation automatically corrected for filename case. The
new implementation expects that the supplied filename can be passed to
PYHSFS_openRead as-is. All known uses in-game have been corrected to
satisfy this requirement. If the new stricter match requirement becomes
a problem, a variant of PHYSFSRWOPS_openRead that adjusts filename case
could be created for use here.
- Update install instructions
- Update ebuild
- Update Arch PKGBUILD
gcc-10 warns that the game information text may be truncated, because it
overestimates the maximum possible length of some strings. Handle the
warning by changing the format string to explicitly truncate these
strings at their maximum legal lengths.
gcc-10 warns that if immediate_directories were very large, the sprintf
result would be truncated. This is true, but a user is extremely
unlikely to have enough directories to trigger this code path. Handle
the warning by explicitly returning an empty string if truncation would
otherwise occur. This is not strictly correct, but it can be handled
with very little code, eliminates the warning, and is unlikely to matter
in practice.
As reported in pull #507, the D1 implementation of the reduction was
incorrect and never reduced laser power. Therefore, when D2 emulates
D1, D2 should emulate the effect of the bug, by not reducing laser
power.
The code that provides the 0.75x multiplier to laser bolts when they're fired
using the quad laser is present in D1 as in D2, however it is incorrect and
results in it not being applied. As such, it is more accurate to exclude the
multiplier when compiling D1.
Thanks to SaladBadger for the tip.
Commit 2bcc7bb371 restricted
Laser_create_new to only create lasers for known weapon types. This
seemed like a good idea, but broke custom levels that use undocumented
laser types. It also replaced logic that coerced invalid weapon numbers
into a type 1 laser with logic that prevented firing such weapons at
all. This rendered robots with unknown or broken weapon data unable to
fire.
Commit 0c30fa7cf3 relaxed the logic to
prevent firing only in editor builds, but allow firing unknown or
invalid weapon types in release builds. Firing unknown weapon types may
work. Firing invalid weapon types may cause the game to crash when data
is accessed beyond the end of the defined weapon data. This caused the
crash reported in issue #506.
Revert to the 0.58.1 rule that invalid weapons are coerced to be a
player level 1 laser. Add a diagnostic when such a weapon is fired,
since the level author should have requested that weapon explicitly if
that was intended.
Reported-by: heftig <https://github.com/dxx-rebirth/dxx-rebirth/issues/506>
Fixes: 2bcc7bb371 ("Only create lasers for known weapon types")
newpath is a std::array and does not decay to char* automatically.
Use data() method to get char[], which does decay to char*.
This compile-time issue only affected Mac OS X.
The minimum supported compiler versions now provide a depth-efficient
implementation of std::make_index_sequence, which removes the last
reason to carry a private implementation. In the case of clang, it
appears to have a special compiler intrinsic used to implement its
std::make_index_sequence.
Switch to the compiler-provided version for both gcc and clang.
gcc-4.9 support is now difficult to test due to system libraries linking
to newer symbols. gcc-4.9 is unsupported upstream, as are gcc-5 and
gcc-6. Raise the minimum required gcc version to the minimum version
supported upstream.
Debian Jessie shipped gcc-4.9.2, and support for this target was the
primary motivator for retaining gcc-4.9 support. Jessie ended regular
support in June 2018, and will end Long Term Support in June 2020. It
seems unlikely that Jessie would receive a snapshot build of Rebirth in
the months it has left.
Debian Stretch shipped gcc-6, but is currently considered "oldstable"
and has been superseded by Debian Buster. Further, Debian Stretch
provides a package for gcc-7, so Stretch users can still build Rebirth
using only packages available from the package manager.
Commit d355ef4030 removed a seemingly unnecessary modification of the
global variable grd_curcanv->cv_font, after eliminating all local reads
of it. However, a non-local read, buried in listbox_mouse, depended on
grd_curcanv->cv_font being set to a MEDIUM font. After that commit,
grd_curcanv->cv_font retained its prior value, which is not a MEDIUM
font. This caused listbox_mouse to compute an incorrect height of the
lines in the listbox, which manifested as the game choosing the wrong
line when the mouse is clicked in the listbox.
Fix the problem by explicitly using MEDIUM3_FONT, since that was
usually the value left in grd_curcanv->cv_font prior to that commit. In
some cases, a different MEDIUM font would be left there, but all the
MEDIUM fonts have the same height, so they are interchangeable for this
purpose.
Reported-by: Q3BFG10K <https://github.com/dxx-rebirth/dxx-rebirth/issues/498>
Fixes: d355ef4030 ("Pass font to various drawing functions")
andrew-strong reported that using SDL2, with the window set to full
screen, but a windowed size less than full screen, caused letterbox
sequences, such as the player ship destroyed sequence, to render in a
subwindow sized to the dimensions game would have when unmaximized, even
if the game window is maximized at the time of the sequence.
tycho suggested a change that resolves this issue, and basic testing
showed no unwanted side effects.
Reported-by: andrew-strong <https://github.com/dxx-rebirth/dxx-rebirth/issues/399>
Suggested-by: tycho <https://github.com/dxx-rebirth/dxx-rebirth/issues/399#issuecomment-583688998>
ziplantil reported that in Descent 1, if a player has an empty Vulcan
cannon, and no energy, then attempting to fire a weapon would play the
SOUND_ALREADY_SELECTED clip every frame until the player ceased trying
to fire. The problem does not impact Descent 2 since Descent 2 does not
play this sound sample when trying to activate a weapon that is already
active.
If the current weapon is already LASER_INDEX, then
select_primary_weapon(LASER_INDEX) simplifies to:
```
// Pointless, player already using this weapon
newdemo_record_player_weapon(LASER_INDEX)
if (Primary_weapon != LASER_INDEX) {
// skipped, path is false
}
else
{
if (wait_for_rearm) // true for this path
// Bad, plays every frame
digi_play_sample(SOUND_ALREADY_SELECTED);
}
// Pointless, Primary_weapon already is LASER_INDEX
Primary_weapon = LASER_INDEX;
if (weapon_name)
{
// skipped, path is false
}
```
Skipping the call avoids two pointless statements, one bad statement,
and nothing useful. Therefore, the simplest fix for the problem is to
call select_primary_weapon(LASER_INDEX) only if the primary weapon is
not currently LASER_INDEX.
Reported-by: ziplantil <https://github.com/dxx-rebirth/dxx-rebirth/issues/499>
Read the entire buffer at once, then remove the carriage returns and set
a null terminator. This reduces the number of calls to PHYSFS_read from
len to 1.
It reads uninitialized values, so it was barely functional before
morph_data became a dynamic allocation, and it is broken now. Disable
it to avoid crashing the game. The demo code should have initialized
the morph_data structure properly, but does not.
Reported-by: tycho <https://github.com/dxx-rebirth/dxx-rebirth/issues/496>
Fixes: cac5f1da56 ("Move morph_data into dynamic allocations")
When building with AddressSanitizer, gcc warns that `i` may not fit,
because the compiler fails to adequately constrain the possible values
for `i`. Add a control-flow hint to inform gcc about valid values.
These variables are used, but optimized builds eliminate all reference
to their address, so the build normally succeeds. Unoptimized builds
retain references to the address, so a definition is required for them.
Reported-by: tycho <https://github.com/dxx-rebirth/dxx-rebirth/issues/496>
Fixes: 595c3ca086 ("Move Boss_cloak_interval to d_level_shared_boss_state")
Fixes: c61dee7e6a ("Move Boss_teleport_interval to d_level_shared_boss_state")
Returning from a secret level clears the player's `hostages_on_board` to
0 as part of initializing a "new" ship, but this is not desirable
behavior. Copy the counter out before and back afterward.
```
Thread 1 "d2x-rebirth-edi" hit Hardware watchpoint 1: -location d2x::LevelUniqueObjectState.Objects._M_elems[0].ctype.player_info.mission.hostages_on_board
Old value = 5 '\005'
New value = 0 '\000'
#0 d2x::init_player_stats_ship (GameTime64=<optimized out>, plrobj=...) at similar/main/gameseq.cpp:613
#1 d2x::init_player_stats_level (secret_flag=d2x::secret_restore::survived, plrobj=..., plr=...) at similar/main/gameseq.cpp:615
#2 d2x::StartNewLevelSub (level_num=level_num@entry=3, page_in_textures=page_in_textures@entry=1, secret_flag=secret_flag@entry=d2x::secret_restore::survived) at similar/main/gameseq.cpp:1901
#3 d2x::state_restore_all_sub (LevelSharedDestructibleLightState=..., secret=d2x::secret_restore::survived, filename=<optimized out>) at similar/main/state.cpp:1670
#4 d2x::state_restore_all (in_game=in_game@entry=1, secret=secret@entry=d2x::secret_restore::survived, filename_override=<optimized out>, blind=blind@entry=dcx::blind_save::no) at similar/main/state.cpp:1490
#5 d2x::ExitSecretLevel ()
```
Reported-by: teratorn <https://github.com/dxx-rebirth/dxx-rebirth/issues/495>
Commit d879fc7f6b changed the type of `newpath` and updated all uses
in common code. A Windows-only block was skipped. Update that now.
Fixes: d879fc7f6b ("Convert file selection to use array<char, N>, not char[N]")
When presented with an overlong string, throw std::runtime_error instead
of corrupting memory. Either way, the result is a crash, but this crash
is safe, deterministic, and probably easier to debug.
The historical savegame format cannot support finding a mission in a
subdirectory. Add a backwards-incompatible modification to store the
full path in the savegame, and store it in a way that old versions will
fail gracefully.[1] When loading demos, or legacy savegames, search for
the mission in all available directories. Demos are still written with
an unqualified path because the demo loading code would crash if given
an oversized path. Mission names sent over the network as part of
multiplayer use the guess logic now, so that guests do not need to have
the mission in the same path as the host.
[1] Versions affected by issue #486 may fail ungracefully.
Reported-by: AlumiuN <https://github.com/dxx-rebirth/dxx-rebirth/issues/491>
- In D2X, do not accept Descent2-specific directives from Descent 1
`.msn` files.
- Set the descent_version field correctly in the `mle`. Previously,
`.msn` was set to descent1 and all `.mn2` were set to descent2,
regardless of whether the `.mn2` used `name`, `xname`, `zname`, or
`!name`.
- Avoid rewinding the file and rereading the same line while checking
the possible name types.
- Avoid recomputing end-of-string when it is already known.
- Avoid re-reading the mission file's version when the mission is
chosen. Instead, use the version that was recorded when the mission
was loaded into the mission list. This also fixes a bug where Descent
1 `.msn` files would be classified as descent_version_type::descent2
since both use `name =`, but that string has a different meaning
depending on whether the file is `.msn` or `.mn2`.
Some levels have robots with n_joints=0 and an invalid offset. If the
number of joints is zero, the offset is irrelevant. Reset it to 0, so
that a later call to partial_range will not trap.
Reported-by: kakhome1 <https://github.com/dxx-rebirth/dxx-rebirth/issues/485>
TORRaven reported an issue where `Descent: First Strike` level 4 in
cooperative games would cause the player 0 ship to be unable to move.
On investigation, this occurs when the host has enabled extra player
starts, and the resulting synthesis of new player start positions moves
the player 0 start out of its origin segment. The physics engine reacts
poorly to this situation, causing the object to be unable to move and to
report HIT_BAD_P0 in debug builds. Add a test to cancel the
displacement if get_seg_masks reports that the center point would move
outside the origin segment. More clever logic might be appropriate, but
since this is the first report of problems with the feature since its
introduction in 5a64ee5132, this commit just eliminates the
immediate problem. Possible future improvements if the existing
displacement causes collisions:
- Reduce the magnitude of the existing displacement, instead of
abandoning it entirely.
- Move the player start to the segment's center before displacing it.
- Add logic to move the player into a nearby logically connected
segment.
Reported-by: TORRaven <https://github.com/dxx-rebirth/dxx-rebirth/issues/483>
Fixes: 5a64ee5132 ("Add experimental support for larger cooperative games")
