When a scene-forced/fixed camera (e.g. the Spirit Temple boulder-room
alcoves, CAM_SET_PREREND_FIXED / Camera_Fixed3) drives the view, the Free
Look angles in play->camX/camY are left untouched while manualCamera stays
set. On exit, Camera_Free resumed from those stale pre-alcove angles, so
the camera snapped/reversed instead of following the player out.
This does NOT change the forced-camera behavior: the alcove still clamps
exactly as the game intends. It only fixes the hand-off back to Free Look:
when Camera_Free resumes after another camera function drove the previous
frame (detected via a frame-number gap), the free-look yaw/pitch are
re-seeded from the camera's current orientation so the view continues from
where it was left.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* fix(camera): let free look release the door peek camera
After walking through a door, the door camera (CAM_SET_DOORC) held the view and
only handed control back once the player moved or pressed a button, so the right
stick did nothing until then. With free look the camera appeared frozen after
every door.
Treat right-stick movement as a release condition too, using the same stick
threshold as free-look activation.
* refactor(camera): move door-cam free-look release to a VB_SHOULD hook
Reimplements the door peek camera free-look release as a vanilla-behavior
hook instead of inline logic in z_camera.c, keeping the decomp file close
to upstream.
- Add VB_RELEASE_DOORC_CAMERA wrapping the existing Camera_Special9 release
condition; the vanilla button/xzSpeed expression is left untouched.
- Move the right-stick / free-look threshold logic into a new enhancement,
FreeLookDoorCamRelease.cpp, registered with COND_VB_SHOULD and gated on
FreeLook.Enabled so the hook only exists while Free Look is on.
Behavior is unchanged from the previous fix; this only relocates the logic.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Free Look pinned the camera to the fixed "Camera Distance" setting, so it never
pulled in or out the way the vanilla camera does for the current situation.
Add an opt-in "Follow Default Camera Distance" setting (FreeLook.UseGameDistance)
that uses the game's per-mode default distance instead. The fixed distance slider
is hidden while it is enabled.
Closes#4050
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
The custom-sequence registration loop printed each assigned seqNum to
stdout via a bare printf, spamming the console with context-free numbers
on every launch. Convert it to LUSLOG_DEBUG and include the sequence name
so it is hidden by default yet useful for diagnosing music-pack loading.
The resolved replacement id (which can exceed 255) rode a single
per-player seqToPlay slot, written at enqueue but consumed
asynchronously on the audio thread; back-to-back starts and
priority-queue promotions clobbered it. sSeqFlags[0x6F] was also indexed
by raw id, reading out of bounds past the authentic range.
- func_800F9280 resolves the replacement and packs the full 16-bit id
into the 0x82/0x85 play command; the handler reads opArgs & 0xFFFF.
Audio_QueueSeqCmd no longer pre-writes the shared slot.
- SyncInitSeqPlayerInternal uses the command-carried id and bounds-checks
it against the calloc'd sequence map (+0xF headroom for reserved-range
skips).
- Route sSeqFlags reads through a bounded Audio_GetSeqFlags helper.
- Warn and skip gracefully past the 16-bit id limit.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Item_CheckObtainability should only be called with MOD_NONE GI
For RG_DOUBLE_DEFENSE that became ITEM_FISH. Nonsense ensued
To reproduce issue, create debug save & go straight to OGC great fairy with only magic/ocarina/lullaby
Add explicit alt prefix checking to animation loading
Makes ResourceMgr_LoadAnimByName alt-toggleable this will work for Link and any other animations files
Before I had the change back to the placeholder actor id the Dummy
Player actors were spawned with, but since we grabbed the actorDB
entry before Actor_Destroy was called it didn't matter. Move it
and the requisite log statement to after Actor_Destroy.
The sampleDataStartPad and aligned variables existed solely to satisfy
the N64 RSP DMA requirement that source addresses be 16-byte aligned.
On PC, aLoadBuffer is a plain memcpy with no such constraint.
The alignment dance caused aLoadBuffer to read up to 15 bytes before
sampleData and up to 8+ bytes past the end of the sample buffer. On
platforms with strict allocator guard pages (e.g. OpenBSD), this
triggers a SIGSEGV.
A second issue remains after removing the alignment dance: nFramesToDecode
is derived from sample counts (loopEnd), but size is not always a multiple
of frameSize. loopEnd and size are derived independently during encoding
and can disagree on the final partial frame, leaving nFramesToDecode *
frameSize exceeding the remaining bytes in the buffer.
Remove sampleDataStartPad and aligned entirely. Clamp the load to
min(nFramesToDecode * frameSize, audioFontSample->size - sampleDataOffset).
The ADPCM decoder operates on DMEM, so a partial last frame in DMEM
produces at most a negligible artifact at sound termination.
Change Actor_SpawnEntry to use VB
Move adult zelda collapse stalfos to a explicit hook
Move dark link to a explicit hook
Some more canRandomize that were not needed
Move bg_haka & bg_haka_tubo to explicit hooks
Move en_vali to an explicit hook
Move bg_mori_bigst to an explicit hook
Fix door opening before the enemies are killed
Remove `canRandomize` parameter
Move bg_haka_huta to explicit hooks
Tim Schneeberger