feat(mac-os): build and run successfully #489
Conversation
…face support for macOS rendering
…size support Replaces stub darwin implementation with full Cocoa/AppKit windowing system including mouse events, coordinate conversion, NSWindowDelegate-based resize handling, and DPI calculations to match Windows functionality
… editor - Add NSEventTypeFlagsChanged handler for modifier key detection (Cmd, Ctrl, Shift, Alt) - Map macOS Command keys to Ctrl in keyboard mapping for clipboard shortcuts - Implement Cocoa windowing functions: - Clipboard operations (copy/paste with NSPasteboard) - Window management (position, size, title, focus, destruction) - Cursor variants (standard, I-beam, resize cursors) - Cursor visibility controls (show/hide) - Asset loading from application bundle - Implement file browser native dialogs using osascript - Fix directory operations for macOS (getcwd, file exists checks) - Add comprehensive macOS build documentation including Vulkan SDK setup and Soloud build instructions This enables full editor functionality on macOS with proper keyboard shortcuts (Cmd+C/V/X), clipboard integration, and native windowing behavior.
src/platform/windowing/windowing.h
Outdated
| #if defined(_WIN32) || defined(_WIN64) | ||
| #include "win32.h" | ||
| #elif defined(__android__) | ||
| #elif defined(__ANDROID__) |
There was a problem hiding this comment.
I know this is still a draft, but thought I'd drop this in case it was missed:
This is likely defined by the NDK, we could also make this:
#elif defined(__android__) || defined(__ANDROID__)There was a problem hiding this comment.
yeap this is still a draft I'm implementing what is left for the cursor and the window stuff but I will add this too 👍
…ck, and raw mouse input logic matching Windows
|
I'm sure this needs some polish but the best way to do this will be keep iterating actually doing games. Also idk why the tests are failing, tomorrow I will run it in a linux machine to test it |
src/platform/windowing/x11.c
Outdated
| /******************************************************************************/ | ||
|
|
||
| #if (defined(__linux__) || defined(__unix__)) && !defined(__ANDROID__) | ||
| #if (defined(__linux__) || defined(__unix__)) && !defined(__android__) || defined(__ANDROID__) |
There was a problem hiding this comment.
It seems this directive will still trigger when __ANDROID__ is defined.
There was a problem hiding this comment.
thank you! this is my bad doing some find and replace all. I will fix it in the next commit
| /* | ||
| #cgo darwin CFLAGS: -DVK_USE_PLATFORM_MACOS_MVK -Wno-deprecated-declarations | ||
| #cgo darwin LDFLAGS: -F/Library/Frameworks -framework Cocoa -framework IOKit -framework IOSurface -framework QuartzCore -framework Metal -lvulkan | ||
| #cgo darwin LDFLAGS: -F/Library/Frameworks -framework Cocoa -framework IOKit -framework IOSurface -framework QuartzCore -framework Metal -L/usr/local/lib -lMoltenVK -Wl,-rpath,/usr/local/lib |
There was a problem hiding this comment.
Currently, the LDFLAGS are hardcoded. What if the developer could specify the include and library paths via CGO_CFLAGS and CGO_LDFLAGS (for example, using $VULKAN_SDK), since the Vulkan SDK might be installed in a non-standard location? This would make the build process more flexible and portable.
Example build command:
CGO_CFLAGS="-I$VULKAN_SDK/include" CGO_LDFLAGS="-L$VULKAN_SDK/lib -lMoltenVK -Wl,-rpath,$VULKAN_SDK/lib" go build -tags editor -o kaiju-editor .
There was a problem hiding this comment.
You can still use the env vars if you need to. Having those defaults in the go file looks sensible to me, especially since macos is standardized.
|
Hi @pato98115 ! Great job! I get the following error when building on macos arm: rendering/vulkan/types.go:3591:31: could not determine what C.VkAccelerationStructureNVX refers to
rendering/vulkan/types.go:2878:32: could not determine what C.VkIndirectCommandsLayoutNVX refers to
rendering/vulkan/types.go:2875:21: could not determine what C.VkObjectTableNVX refers toI'm hardly familiar with the Vulkan SDK, is NVX some kind of extension? I created dummy types for macos and the build/launch of the editor was successful. |
… vulkan bindings types
On macos at least, a few env vars need to be set in order to compile (CGO_LDFLAGS="-L/usr/local/lib -lMoltenVK -Wl,-rpath,/usr/local/lib").
Feat/mac os run
…ts and remove unkonw buildEnv() call
|
The physics library is prepared to go into the Sorry for this coming in now, but I figured it'd probably be good to have the physics library ready on mac too for the merge. |
|
Additional note, this caps-lock PR has been merged. That shouldn't require anything from the Mac port. However, there is 1 function in there that needs to be filled out (on Win, Mac, and Android still) to get the current state of the toggle keys at window creation. |
… caps lock check toggle
… related stuff in the main os thread (as apple wants)
|
Great work on your efforts to get this running on macOS! I've managed to build and run Kaiju in debug mode on macOS 15.6.1 on arm64 by following the instructions here. I've noticed a bug that occurs on window resize. The window goes unresponsive for a few seconds while many messages are written to the log, before it panics. In the attached logs:
Panic message: My system info: Is there anything I can do to help resolve this? |
|
Furthermore, when quitting, either in a project or at the main menu, it seems to hang at |
|
Hi @mikenye 👋 I’ll take a look at this today after work and see if I can reproduce the issue on my side. I’m currently fixing parts of cocoa_window.m because I realized I was handling OS interactions incorrectly (I was accessing AppKit outside the main thread). I also discovered that macOS follows a different interaction model than Windows — Windows is polling-based, while macOS is event-driven — so I suspect the issue you’re seeing is related to that. Once I push these changes, it would be great if you could try building again and let me know if the problem still happens — that would help a lot. And if you’re familiar with Objective-C, feel free to take a look at the Cocoa file and suggest improvements as well 🙂 |
|
Hi @pato98115, Unfortunately my knowledge is limited to Go and Python, so I’m not sure I can be much help with the Objective-C code, I’m afraid. :( However, I’ve submitted a PR to your working branch that adds macOS testing to the CI pipeline: Hopefully this is useful to you and the wider project. I’ve also tested the workflow here: It appears to be working correctly. I had to detach the fork so that I could test the action independently. |
|
Hi all, I have updated pato98115#2 which resolves the "crash on resize" issue discussed above. For transparency: the additional commits from pato98115@92f5300 onwards were done with the assitance of OpenAI's Codex, so I would appreciate a review by a more experienced developer. As discussed in the updated PR, there are still some issues with visual corrution on window resize that I am investigating but so far have been unable to pinpoint the issue.
A screen recording is attached to this comment demonstrating the behaviour. Screen.Recording.2025-12-27.at.11.22.25.am.mp4 |
Can you try building this fork & branch to see if your issue is fixed: https://github.com/mikenye/kaiju/tree/feat/mac-os-run ? |
[mvk-error] VK_ERROR_NATIVE_WINDOW_IN_USE_KHR: vkCreateSwapchainKHR(): pCreateInfo->oldSwapchain does not match the VkSwapchain that is in use by the surface
[mvk-error] VK_ERROR_NATIVE_WINDOW_IN_USE_KHR: vkCreateSwapchainKHR(): pCreateInfo->oldSwapchain does not match the VkSwapchain that is in use by the surface
[mvk-error] VK_ERROR_NATIVE_WINDOW_IN_USE_KHR: vkCreateSwapchainKHR(): pCreateInfo->oldSwapchain does not match the VkSwapchain that is in use by the surface
[mvk-error] VK_ERROR_NATIVE_WINDOW_IN_USE_KHR: vkCreateSwapchainKHR(): pCreateInfo->oldSwapchain does not match the VkSwapchain that is in use by the surface
[mvk-error] VK_ERROR_NATIVE_WINDOW_IN_USE_KHR: vkCreateSwapchainKHR(): pCreateInfo->oldSwapchain does not match the VkSwapchain that is in use by the surface
[mvk-error] VK_ERROR_NATIVE_WINDOW_IN_USE_KHR: vkCreateSwapchainKHR(): pCreateInfo->oldSwapchain does not match the VkSwapchain that is in use by the surface
[mvk-error] VK_ERROR_NATIVE_WINDOW_IN_USE_KHR: vkCreateSwapchainKHR(): pCreateInfo->oldSwapchain does not match the VkSwapchain that is in use by the surface
[mvk-error] VK_ERROR_NATIVE_WINDOW_IN_USE_KHR: vkCreateSwapchainKHR(): pCreateInfo->oldSwapchain does not match the VkSwapchain that is in use by the surface
[mvk-error] VK_ERROR_NATIVE_WINDOW_IN_USE_KHR: vkCreateSwapchainKHR(): pCreateInfo->oldSwapchain does not match the VkSwapchain that is in use by the surface
panic: failed to allocate descriptor sets
goroutine 21 [running, locked to thread]:
kaiju/klib.MustReturn2[...]({0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, ...)
/Users/mohammed/projects/kaiju/src/klib/checks.go:63 +0x104
kaiju/rendering.(*RenderPass).setupSubpass(0x140000e0c08, 0x140000c7110, 0x140001c4008, {0x10b289cb8, 0x140000cc038}, 0x1)
/Users/mohammed/projects/kaiju/src/rendering/vk_render_pass.go:115 +0x3d4
kaiju/rendering.(*RenderPass).Recontstruct(0x140000e0c08, 0x140001c4008)
/Users/mohammed/projects/kaiju/src/rendering/vk_render_pass.go:441 +0xec0
kaiju/rendering.(*Vulkan).remakeSwapChain(0x140001c4008, {0x10b27fc80, 0x140000fc008})
/Users/mohammed/projects/kaiju/src/rendering/renderer.vk.go:373 +0x540
kaiju/rendering.(*Vulkan).ReadyFrame(0x140001c4008, {0x10b27fc80, 0x140000fc008}, {0x10b28eee0, 0x140000a28c0}, {0x10b28eee0, 0x140000a2a80}, {0x14000300008, 0x0, 0x14}, ...)
/Users/mohammed/projects/kaiju/src/rendering/renderer.vk.go:438 +0x98
kaiju/engine.(*Host).Render(0x140000fa008)
/Users/mohammed/projects/kaiju/src/engine/host.go:487 +0x158
kaiju/engine/host_container.(*Container).Run(0x140000ba360, 0x3b0, 0x1f4, 0xffffffffffffffff, 0xffffffffffffffff, {0x0, 0x0})
/Users/mohammed/projects/kaiju/src/engine/host_container/host_container.go:96 +0x434
created by kaiju/bootstrap.bootstrapLoop in goroutine 3
/Users/mohammed/projects/kaiju/src/bootstrap/bootstrap_game.go:90 +0x174I got this after pulling your updates, it works well until i tried to resize, it just crashed I'm on Apple M4, 2024 |
Thanks for letting me know. I thought I’d fixed the resize crash but I guess not. I’ll have to leave it to the professionals. :-) |
Yes, it solves my problem! |
This worked, i just tried adding ld flags and enabling cgo |
That’s great! |
Are you seeing the glitches when resizing as-per here: #489 (comment) ? |
Yes, it's like that |
6 participants
Issue #485
Summary
This PR completes the macOS port with full Cocoa windowing, keyboard/mouse input, and clipboard support. The editor is now fully functional on macOS with native platform integration.
Changes by Component
Windowing (Cocoa)
cocoa_window.h/cocoa_window.m(NSWindow/NSView, CAMetalLayer, event polling, clipboard, cursor, asset loading, resize handling, SharedMem integration)window.darwin.go(all windowing methods, cgo directives)window.darwin.vk.go(Vulkan surface creation)cgo_stub_darwin.m,window_darwin.goInput System
keyboard.darwin.go(full macOS key mapping, Cmd→Ctrl remap)cocoa_window.m(modifier key detection, mouse/keyboard event processing)File System & Dialogs
directory_darwin.go(directory ops)file_browser_overlay.go(native dialogs via osascript)Vulkan/MoltenVK
vk_default_loader.c(dynamic MoltenVK loading)vulkan_darwin.go(surface creation)shared_mem.h,windowing.h(macOS compatibility)Documentation
build_from_source.md(macOS build instructions)Technical Details
Testing Status
Current Limitations
Testing Instructions:
cd src && CGO_ENABLED=1 go build -tags="editor" -o ../bin/kaiju../bin/kaijuDependencies:
Closes #485