fix(audio): guard FP environment at all audio entry points - #226
Merged
Conversation
Audio code invoked from the main thread (miniaudio, OpenAL, video audio streaming) can leave the FP environment in a state that skews game math on macOS/ARM - observed as wrong-tile mouse picks (#215) and music affecting physics calculations on non-x86 platforms. init(), update() and addAudioEvent() were already guarded; extend ScopedFPUGuard to the remaining public entry points of MiniAudioManager, OpenALAudioManager and MiniAudioStream so the engine FP mode is re-asserted whenever audio work returns to game code mid-frame.
This was referenced Jul 20, 2026
fbraz3
pushed a commit
that referenced
this pull request
Jul 21, 2026
Follow-up to #222 addressing review feedback from @meerzulee: - Move the single setFPMode() call into getPickRay(), the shared chokepoint used by screenToTerrain(), pickDrawable(), screenToWorldAtZ() and others, so all pick paths are covered by one guard. Remove the two now-redundant calls. - Reword the comments to describe a defensive FP-mode re-assert. The previous wording stated an "audio-thread FP env leak" as fact, which is incorrect: FPU state is per-thread (FPCR on arm64). The likely cause is main-thread audio work altering the FP mode, addressed separately in #226. Closes #227 AI-assisted: change authored with Claude. Compiles clean on macOS/ARM; in-game re-test pending (will confirm on the PR). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #222 for the audio side.
Audio code called from the main thread can leave the FP environment in a bad state on macOS/ARM. We've seen this as wrong mouse picks (#215) and as music affecting physics on non-x86.
init(), update() and addAudioEvent() already had ScopedFPUGuard, but the other entry points didn't. This adds the guard to all of them in MiniAudioManager (which macOS actually uses), OpenALAudioManager (including selectProvider and friend_forcePlayAudioEventRTS), and MiniAudioStream for video audio. readPCM/seekPCM run on the mixer thread, so I left those alone.
Mechanical change, 44 guard insertions and one include.
FPU state is per-thread, so fixing the mixer thread wouldn't help. The problem has to come from audio work running on the main thread, and guarding every entry point closes that window wherever it happens.
I don't have the Vulkan SDK on this machine, so relying on CI for the build. I boot-tested the #222 artifact and confirmed macOS uses the MiniAudio backend.
Two separate follow-ups remain: music decodes whole tracks synchronously on the main thread (causes the gaps at track changes), and there are still unguarded pick paths on the view side, as discussed in #222.
AI disclosure per CONTRIBUTING: written with AI assistance (Claude), reviewed by me.