Skip to content

bugfix(macos): Invert the SDL3 mouse wheel reported as SDL_MOUSEWHEEL_FLIPPED#168

Merged
fbraz3 merged 2 commits into
fbraz3:mainfrom
msmesoft:bugfix/macos-mouse-wheel-direction
Jun 19, 2026
Merged

bugfix(macos): Invert the SDL3 mouse wheel reported as SDL_MOUSEWHEEL_FLIPPED#168
fbraz3 merged 2 commits into
fbraz3:mainfrom
msmesoft:bugfix/macos-mouse-wheel-direction

Conversation

@msmesoft

@msmesoft msmesoft commented Jun 18, 2026

Copy link
Copy Markdown

Problem: macOS natural scrolling flags wheel events as SDL_MOUSEWHEEL_FLIPPED, so the in-game zoom/scroll runs backwards regardless of the OS setting.

Fix: Invert the wheel delta when the SDL_MOUSEWHEEL_FLIPPED flag is set, in SDL3Mouse::translateWheelEvent, so the direction matches the Windows convention. Applied to both Zero Hour (GeneralsMD) and the base Generals SDL3 mouse backend, which share identical code (one commit each).

Testing: In a Zero Hour battle on Apple Silicon (M4 Pro), mouse wheel up zooms in and wheel down zooms out — matching the Windows behavior, with macOS natural scrolling enabled. The base Generals change is the identical mirror of the verified Zero Hour fix.

AI assistance disclosure (per CONTRIBUTING): Diagnosed and drafted with AI assistance (Claude Opus 4.8); I reviewed and adjusted every line and verified the behavior at runtime on Apple Silicon before submitting.

…_FLIPPED

macOS natural scrolling reports wheel events as SDL_MOUSEWHEEL_FLIPPED, so the in-game
zoom and scroll run backwards regardless of the OS setting. Invert the wheel delta when
the flipped flag is set so the direction matches the Windows convention.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@fbraz3

fbraz3 commented Jun 18, 2026

Copy link
Copy Markdown
Owner

Hey @msmesoft thank you very much for contributing! Can you please backport this patch to generals base game?

Apply the same SDL_MOUSEWHEEL_FLIPPED inversion to the base Generals SDL3 mouse
backend that the previous commit applies to Zero Hour, so both titles get the
correct macOS scroll direction. The code in both backends is identical.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@msmesoft

Copy link
Copy Markdown
Author

Thanks for the quick review! I've applied the base Generals backport in the same PR as requested.

While testing GeneralsX on Apple Silicon (M4 Pro) I found and fixed a few other macOS-specific issues — build setup (VULKAN_SDK / SDL3 for DXVK), the saved-resolution window, the fullscreen default, and the black cinematic briefings (MoltenVK view filters). I'll submit them as separate focused PRs, each mirrored for both Generals and Zero Hour where applicable. Happy to adjust to your preferences.

@fbraz3

fbraz3 commented Jun 19, 2026

Copy link
Copy Markdown
Owner

Thank for the backport, i'm having some issues with actions validation but the pr is ok and i'm forcing merge it.

About the black cinematic and resolution issues, can you please provide mor details? I'm asking because in my local environmet, a M1 mac running tahoe, it's working fine.

@fbraz3 fbraz3 merged commit 2737e4d into fbraz3:main Jun 19, 2026
10 of 16 checks passed
@msmesoft

Copy link
Copy Markdown
Author

Thanks for merging! 🙏

Black cinematic: It appears on scripted mission briefings that enable the black-and-white camera filter (the "Black & White Mode" camera script action → ScriptActions::doBlackWhiteModeFT_VIEW_BW_FILTER). Easiest repro: USA campaign, mission 1 — the intro briefing shows as a solid black screen with only the typewriter narration audio.

Two possibilities, easiest to rule out first:

  1. The scenario you tested may not trigger the filter — could you try that exact briefing? (Skirmish and normal in-game views use no view filter, so they look fine.)
  2. If that briefing renders correctly for you, it's likely a GPU-specific MoltenVK shader-translation difference (your M1 vs my M4 Pro, both on Tahoe).

I instrumented W3DShaderManager/W3DView, and the [CINE-FILTER-DIAG] traces show FT_VIEW_BW_FILTER activating while the rendered frame stays solid black; skipping that shader-based filter on macOS renders the scene in color (targets, base, typed briefing). I can attach those logs if useful.

Resolution: Minor polish — the SDL3 window is created at a hard-coded 1024×768 and only resized to the saved resolution afterwards, so it briefly opens at the wrong size on launch. If your Options.ini is already 1024×768 you wouldn't notice. Feel free to skip it if you prefer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants