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.
Max Roncace