This is initial setup to enabling use of zip() on sentinel based ranges.
Store the range's type in the zip signature, and store the types of
std::begin/std::end for the iterators, rather than assuming that
std::begin and std::end return the same type.
Allow the caller to pick which sequences can terminate the zip iterator.
For compatibility and performance, default to the historical behavior of
examining only the first sequence. The zip iteration terminates when
any of the examined sequences reaches its end, even if other sequences
have not reached their respective end.
The standard type imposes some additional requirements that are not
necessary here, but using this concept allows standard containers to be
classified correctly without specific overrides.
Any integer type can convert to match this signature, but the diagnostic
will only report that this deleted function was matched. Switch to a
template function so that the diagnostic can report the unconverted
integer type.
Switch from using a macro to capture __FILE__,__LINE__ to using
__builtin_FILE(),__builtin_LINE(). Make the event an explicit argument,
instead of assuming it is a variable named `event`. Move the
implementation out of line.
The global variables that control it configure the callback to do
nothing, but SDL_mixer would still call it and still acquire the SDL
mutex that protects the call. Such calls are a waste, so disable them.
This should also fix
<https://github.com/dxx-rebirth/dxx-rebirth/issues/684>, which appears
to be caused by the MVE mixer callback being run during gameplay, and
the callback not returning immediately. This is suspected to be because
a race condition between MVE_rmEndMovie and the callback caused the
global variables not to be placed in a state that causes the callback to
return immediately.
When building with -D_GLIBCXX_DEBUG, gcc-11 warns:
```
In file included from /usr/include/string.h:535,
from similar/main/net_udp.cpp:14:
In function 'void* memcpy(void*, const void*, size_t)',
inlined from 'virtual void d2x::multi::udp::dispatch_table::send_data_direct(std::span<const unsigned char>, dcx::playernum_t, int) const' at similar/main/net_udp.cpp:5731:8:
/usr/include/bits/string_fortified.h:29:33: error: 'void* __builtin_memcpy(void*, const void*, long unsigned int)' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=]
29 | return __builtin___memcpy_chk (__dest, __src, __len,
| ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
30 | __glibc_objsize0 (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
```
The warning is invalid: the destination buffer is not PTRDIFF_MAX bytes
long, and the requested length is not SIZE_MAX bytes. Both claimed
lengths are the result of excessively cautious value range tracking.
Eliminate the warning by adding a `cf_assert` to assure gcc that
`data.size() != std::dynamic_extent`.
Use printf `%.*s` with an appropriate length, instead of copying the
appropriate number of bytes into a temporary, null terminating it, and
relying on the terminator for printf.
Since this should never be invoked, simplify the definition. The new
version is slightly less informative in case a logic error causes it to
be called, but is far shorter and easier to understand.
Use a std::optional<vms_vector> to store the gun point and a flag of
whether the gun point is valid. This allows deferring computation of
the gun point until it is needed, and avoids recomputing it once it has
been computed. This also fixes an obscure case where a robot with its
gun positioned at 0,0,0 would be incorrectly considered too far away.
Gun point calculation is skipped in do_ai_frame if
dist_to_player >= 200 but a bot might still fire a homing weapon
if it is further away.
Add extra call to calc_gun_point in ai_do_actual_firing_stuff when
a homing weapon is fired without visibility to make sure a valid
gun point is used.
This is an original game bug, shown for example in this video:
https://www.youtube.com/watch?v=2dP51znGh7o
Python3 does not expose an attribute `message` on `Exception`. However,
`Exception` can implicitly convert to a string, and produces the
message. Switch to that.
object_create_muzzle_flash delegated to
object_create_explosion_without_damage, adding one parameter that
callers ought to provide instead. Inline object_create_muzzle_flash into
callers and change them to provide `Vclip`.
