[macOS] Add macOS SDL3 EGL runtime substrate#3060
Conversation
|
split this into sensible commits |
yeojuny
force-pushed
the
codex/macos-runtime-substrate
branch
from
8cec3e1 to
3ff1357
Compare
|
Done. I force-pushed the branch as four focused commits: SDL3/EGL platform layer, macOS Zink GL state adaptation, filesystem/toolchain portability, and Rml/aGui runtime adjustments. Re-validated with |
yeojuny
changed the title
yeojuny
changed the title
sprunk
left a comment
sprunk
left a comment
There was a problem hiding this comment.
I am doubtful about mixing SDL2 and SLD3 and especially about doing it by sprinkling the code with a ton of ifdefs.
|
|
||
| std::string str() const { | ||
| return std::format("float3({:.3f}, {:.3f}, {:.3f})", x, y, z); | ||
| char buf[64]; |
There was a problem hiding this comment.
try fmt::format. if that helps, make a small standalone PR that converts existing std::formats to fmt::format
|
That's fair feedback. The intent here is not to mix SDL2 and SDL3 as runtime dependencies. The original engine path is SDL2-shaped, and the first macOS attempts also followed that route. In practice, the SDL2 path made the macOS display / high-DPI / window-size handling messy enough that the SDL3 route became the cleaner runtime substrate. SDL3 gives us a better fit for the Cocoa/Retina window and drawable-size model, while the existing engine code still expects SDL2-style source and CMake contracts. So under I agree the naming and ifdef surface make this easy to misread. I can tighten the PR description and, if maintainers prefer, follow up by isolating or renaming the compatibility layer so the SDL3 runtime boundary is clearer. |
|
I took another pass at this to make the SDL boundary less ambiguous:
Revalidated with:
The rebuilt binary still links |
|
Possibly, but I think that is a harder task. Adding mac support only touches existing code in limited ways, but a proper SDL3 migration will affect existing rendering widely so has huge potential for regressions (e.g. check wesnoth which recently migrated and got a ton of problems out of it: https://github.com/wesnoth/wesnoth/issues?q=is%3Aissue%20SDL3%20sort%3Aupdated-desc ). I am not sure if I want it to be done by mac vibecoders who have nothing to lose. |
|
Considering the other notable MacOS renderer PR didn't upgrade SDL, I'm inclined to agree on the risk factor |
yeojuny
force-pushed
the
codex/macos-runtime-substrate
branch
from
4753b3b to
6ff2542
Compare
3 participants
Summary
This is a draft PR for the macOS/Apple Silicon runtime substrate used by the BAR.app path.
It adds the platform pieces needed to launch Recoil through SDL3 + EGL on macOS while preserving the Linux/BAR gameplay contract:
Commit layout
The branch is split into four reviewable commits:
Add macOS SDL3 EGL platform layerAdapt GL state for macOS Zink renderingFix macOS filesystem and toolchain portabilityAdjust Rml and aGui for macOS runtimeWhy
The BAR Apple Silicon port should be bar-lobby-first rather than a direct-engine fork. This PR isolates the Recoil-side runtime substrate so the lobby can hand off to a native engine in a reviewable upstream branch.
Validation
git diff 9fdfaad501..HEAD --checkcmake --build /Users/yeojun/Desktop/BAR-AppleSilicon-App/build/recoil-engine --target engine-legacy -j 8The engine target builds successfully. Remaining local linker warnings are about duplicate libraries and deployment-target/newer-dylib closure in the local runtime stack, not a compile failure.
Related draft PRs
Notes for reviewers
This is intentionally draft because runtime closure, signing/notarization, and clean-machine packaging are still tracked outside this Recoil-only change. The expected acceptance path is BAR.app through bar-lobby, not direct
springinvocation.