This could cause a crash and was previously fixed by 3aa39867, but
it's a band-aid solution. This fix addresses the underlying bug that
actually causes the crash.
The workaround remains in place for now because similar bugs related
to NaNs have been encountered, and it's not currently known how many
places in the codebase are affected as well.
This fixes a crash in the first King Bulblin sequence (in Ordon Spring)
as well as in the first cutscene in Renado's sanctuary, and probably
some other sequences too.
This is meant as a band-aid until the upstream fix here is merged:
https://github.com/zeldaret/tp/pull/3136
This fixes intermittent segfaults due to invalid atan table lookups.
For some reason zero-initializing all cXyz objects causes issues, as
does initializing them with INFINITY or -INFINITY. However, at least
one of the possible crashes (in d_a_e_yg's search_ground_1) is
guaranteed to happen whenever a specific uninitialized cXyz contains
a NaN for x or z.
A possible explanation for these crashes not occurring on hardware might
be that the problematic objects happen to be placed at memory locations
that happen to never contain a NaN upon allocation, so the buggy code
was never caught. Further investigation would be needed to determine if
this is what's actually happening, though.
The last argument is used as a char*, so we need to explicitly
pass nullptr instead of 0 to ensure it has the correct type.
This was causing crashes due to va_arg reading 8 bytes when only 4
were provided by the caller - if the out-of-bounds bytes are
non-zero, the null check fails and it continues pulling args from
beyond the argument buffer potentially triggering a segfault.
The framebuffer size flows into Aurora as follows:
Into JUTVideo:
AURORA_WINDOW_RESIZED handler ->
mDoGph_gInf_c::setWindowSize ->
JUTVideo::setWindowSize
From JUTVideo -> dComIfG_play_c:
fpcCt_Handler ->
phase_4 ->
dComIfGp_setWindow
From dComIfGp_play_c -> Aurora:
mDoGph_Painter ->
drawDepth2 ->
GXSetTexCopySrc ->
GXCopyTex ->
aurora::gfx::resolve_pass (called by GXCopyTex)
The trouble is that 1) phase_4 is only called when creating a new scene/room,
and 2) even when it is called, mDoGph_Painter is executed before fpcCt_Handler
in the main loop so the new size isn't visible to aurora::gfx::resolve_pass
until one frame after it's set. This causes a crash due to the original size
being passed to CopyTextureToTexture despite the destination framebuffer now
being smaller.
As a workaround, we just cut out the whole middleman section and call
dComIfGp_setWindow immediately when we receive a resize event. This way the new
size is immediately visible to Aurora.
YunataSavior