MacOS Support

[herrMirto]

Hello, first of all, thank you very much for all efforts on this project. It is really looking amazing!! I would like to know if you have any plans to support also MacOS builds. I did some quick changes locally and managed to start the app and the editor, but unfortunately, imgui seems to be terrible on Mac. I can't read anything and all the menus are very, very small.

[surtarso]

Oh! If you managed to build and run it (that's awesome!) it's just coz currently the DPI settings use Linux bias only. I don't have access to a Mac to test things but adding a mac definition on the DPI detection code should be a one line change really, I'll add it, but I think MacOS needs a .app bundle to activate high DPI.

Now to fully support MacOS (specially stuff that will use commands) there's a couple of things that need to be done, but shouldn't be so hard if it already builds and runs!

Could you explain what you did to compile? I can probably tailor something and let the workflow do it's magic.

Let me know, this is very interesting!

If you want to test it locally real quick, in main.cpp, inside SDLBootstrap()

replace these 2:

        SDL_SetHint(SDL_HINT_WINDOWS_DPI_AWARENESS, "system");
        SDL_SetHint(SDL_HINT_WINDOWS_DPI_SCALING, "1");

with something like this:

        #if defined(__APPLE__)
            #ifdef SDL_HINT_VIDEO_HIDPI_DISABLED
                SDL_SetHint(SDL_HINT_VIDEO_HIDPI_DISABLED, "0");
            #endif
        #endif

or similar and see what happens! ; )

[surtarso]

Yo... check out the latest actions build! =D

https://github.com/surtarso/ASAPCabinetFE/actions

I managed to make it compile into an app bundle (so DPI works). I just have NO IDEA if it works =P

Let me know!

I killed VLC support on MacOS build coz it was giving me trouble to compile and its not 100% needed. also some OS probing methods I just quickly changed to just a warning for now, just to compile. I wouldn't try screenshot mode tho, it's barely ready for Linux builds lol...

Also, its for arm64... if you need x86_64 let me know, I'm looking into it (and the universal fat one) but knowing if the current one works would be nice =)

edit: I got the x86_64 to link 100% but still missing a path detail for the build to finish.. I'll see if I can do it tomorrow.

[herrMirto]

Unfortunately, it doesn't work.

I will try to compile and if it works I will skip my changes, otherwise I can explain the other things I've changed.

"Success" I would say. The Frontend start although without anything as you can see in the picture below:

The Editor, unfortunately, doesn't work. I got this error:
./ASAPCabinetFE-Editor
libc++abi: terminating due to uncaught exception of type std::__1::__fs::filesystem::filesystem_error: filesystem error: in read_symlink: No such file or directory ["/proc/self/exe"]
[1] 43066 abort ./ASAPCabinetFE-Editor

If you want I can create a PR with my changes(with some help from AI). On my branch I can compile and execute both, the frontend and the editor.

[surtarso]

ok, that's not all bad!

./ASAPCabinetFE-Editor
libc++abi: terminating due to uncaught exception of type std::__1::__fs::filesystem::filesystem_error: filesystem error: in read_symlink: No such file or directory ["/proc/self/exe"]
[1] 43066 abort ./ASAPCabinetFE-Editor

I fixed this already (both instances of ["/proc/self/exe"], thats how we get the executable path in Linux so we can find our assets.

add on top of main and config

#if defined(__APPLE__)
    #include <mach-o/dyld.h>
    #include <limits.h>
#endif

and in main(), this is the problematic part (on apple) and my attempt to fix

 #if defined(__APPLE__)
        // macOS: _NSGetExecutablePath + realpath
        uint32_t size = sizeof(path);

        // Try with static buffer
        if (_NSGetExecutablePath(path, &size) == 0) {
            char resolved[PATH_MAX];
            if (realpath(path, resolved) != nullptr) {
                // Executable absolute path, get directory
                exeDir = std::filesystem::path(resolved).parent_path().string() + "/";
            } else {
                // Couldn't resolve symlinks, fallback to raw
                exeDir = std::filesystem::path(path).parent_path().string() + "/";
            }
        } else {
            // Buffer too small, allocate exactly the required size
            std::string dynamicPath(size, '\0');
            if (_NSGetExecutablePath(dynamicPath.data(), &size) == 0) {
                char resolved[PATH_MAX];
                if (realpath(dynamicPath.c_str(), resolved) != nullptr) {
                    exeDir = std::filesystem::path(resolved).parent_path().string() + "/";
                } else {
                    exeDir = std::filesystem::path(dynamicPath).parent_path().string() + "/";
                }
            } else {
                // Completely failed — fallback to CWD
                exeDir = std::filesystem::current_path().string() + "/";
            }
        }

    #else
        // Linux: /proc/self/exe
        ssize_t count = readlink("/proc/self/exe", path, sizeof(path) - 1);     // <- here is what apple doesn't like!
        if (count != -1) {
            path[count] = '\0';
            exeDir = std::filesystem::path(path).parent_path().string() + "/";
        } else {
            exeDir = std::filesystem::current_path().string() + "/";
            LOG_WARN("Failed to resolve executable path, using current directory: " + exeDir);
        }
    #endif

This is exactly what the app is complaining in the picture. but I probably made a mistake on where to find the files on mac side (since its in Resources/ etc inside .app and not alongside the binary as on Linux)

theres 2 instances of it in main.cpp and inside the config.

and the other detail I noticed is the font path, there are no alternative for macs... that's an easy one to add.

you are seeing the DMD window (defaults to on), but you dont know that coz the font didnt load, so theres no text on screen sayin "DMD" and "NO MEDIA".

so if the DMD is there... the backglass and playfields are probably too, maybe on a weird position out of screen (idk how screen bounds work on mac, on Linux the default is "-1" to positon on screen "0,0".)

so this it seems that fixing relative paths and adding mac font options should fix everything I can see on screen...

about the tarball .app bundle I really dont know, I'm shooting in the dark here.

But if you wanna see what I did just search for __APPLE__ in the code or just "APPLE" in cmakelists.txt. thats where all apple ifdefs are. (it's just a few inserts)

a little more on top of this log (not shown) where did the app save settings.json? thats the best hint you can give me so I undnerstand the mac structure.

"If you want I can create a PR with my changes(with some help from AI). On my branch I can compile and execute both, the frontend and the editor."

oh yes! that would be a goldmine! =)

but we're really close!

edit: added some apple font paths to settings.h so the font problem should be gone now.

edit2: the ./ASAPCabinet-Editor is NOT being linked in apple builds, coz the .app bundle can't handle 2 binaries (as far as I quickly read). So I just ommited it. But dont worry, this binary is literally just a shortcut to ./ASAPCabinetFE --editor I created to later add some CLI options apart from the main executable, but you can ignore it on apple and just use -e | --editor on the main binary.

[herrMirto]

I will have a look into the code later on when I finish work. The location of the settings on Mac was this
[Mon Dec 8 11:48:43 2025] INFO: Config Path: /Users/andremichi/workspace/ASAPCabinetFE/build/data/settings.json

Maybe, to keep it more compatible you could use the $HOME variable that works on Mac and Linux(maybe even on Windows)

[surtarso]

the app expects everything to be on the same folder as the executable. changing that might be a little hellish... but for testing purposes, if you edit your settings.json you can correct all paths manually just to see if it works, since after resolving the paths internally it saves them as absolute paths for most things (UI sounds might fail but that's totally fine at this point)

all path related variables are exposed in the json in [internal] settings block

[herrMirto]

Thank you very much for providing updates so quickly. It is really nice from your side. I just compiled the latest changes and it looks kind of promising. Oh, and I am currently testing on a Mac without any extra screen.

What really doesn't work well is the UI. Look how is the frontend

The setup screen:

And this is how the editor looks like:

Also, I can't click or navigate on any options from the editor. As you don't have a Mac I don't know if makes sense to use your time on the changes because I believe imgui is really known for being tricky in different operational systems.

[surtarso]

So I guess if relative paths are corrected it will work just fine, except of course for ImGui... thats kinda awesome, it shouldn't be so hard really, I use a simple imgui manager. But yeah not having a test bed to iterate thru changes sucks...

But it boils down to imgui initial setup calculating its space, its just a couple of lines really.
If you wanna have a go its in /core/ui/imgui_manager but from what I read, we already corrected this with the DPI changes on main()... but apple only accepts hiDPI from .app bundles and that might be what's causing this to you.

Now, in settings.json, for desktop single monitor, you wanna tweak here (since we cant use imgui):

This will configure the "max visible space" for what you want to display

    "WindowSettings": {
        "backglassWindowHeight": 768,
        "backglassWindowWidth": 1024,
        "backglassX": -1,
        "backglassY": -1,
        "dmdWindowHeight": 256,
        "dmdWindowWidth": 1024,
        "dmdX": -1,
        "dmdY": -1,
        "playfieldWindowHeight": 1920,    <--  swap those with you res
        "playfieldWindowWidth": 1080,     <-- swap those with your res
        "playfieldX": -1,
        "playfieldY": -1,
        "showBackglass": true,      <-- set to false
        "showDMD": true,               <-- set to false
        "showTopper": false,
        "topperWindowHeight": 128,
        "topperWindowWidth": 512,
        "topperWindowX": -1,
        "topperWindowY": -1,
        "useVPinballXIni": false,         <-- make sure its false for now to avoid extra steps
        "videoBackend": "ffmpeg"
    }

While here you configure whats being displayed in the above window limits

   "MediaDimensions": {
        "backglassMediaHeight": 768,
        "backglassMediaWidth": 1024,
        "backglassMediaX": 0,
        "backglassMediaY": 0,
        "backglassRotation": 0,
        "dmdMediaHeight": 256,
        "dmdMediaWidth": 1024,
        "dmdMediaX": 0,
        "dmdMediaY": 0,
        "dmdRotation": 0,
        "forceImagesOnly": false,
        "playfieldMediaHeight": 1920,    <--- your res, swap for landscape
        "playfieldMediaWidth": 1080,     <--- do the same as above
        "playfieldMediaX": 0,     <- keep these unless weirdly positioned, you can drag the
        "playfieldMediaY": 0,     <- windows and double click anywhere and it will save current positions
        "playfieldRotation": 0,                <- play with this one till its correct (0,90,180,360 etc)
        "topperMediaHeight": 128,
        "topperMediaWidth": 512,
        "topperMediaX": 0,
        "topperMediaY": 0,
        "topperRotation": 0,
        "wheelMediaHeight": 350,
        "wheelMediaWidth": 350,
        "wheelMediaX": 720,    <-- probably correct this (within window bounds)
        "wheelMediaY": 1550   <-- probably correct this (same for the title as text)
    },

this will get you single screen properly oriented and sized to landscape and media will fit naturally... but the editor will remain unusable since its pure imgui...

[surtarso]

If you care to try the latest build when you have time, I may have fixed the tiny editor issue.

[surtarso]

ok so for the app bundle...
it was invalid coz the data folder was inside the .app resources and we have to write to it... so it throws invalid.
I may have fixed it on the last commit by (probably) sending static and mutable data to the correct places.

these are mostly simple changes here and there encapsulated in apple only builds (doesnt affect the main build) so its not really much trouble. i didnt imagine it would compile so easily, im a complete mac noob.

[herrMirto]

Hello, it's making progress. But as I said, imgui will be really painful.

I also applied the changes on the settings.json as you mentioned.

[surtarso]

yeah =/ from what I could understand, the big problem is screen calculation, coz apple calculates it differently. But it's nothing game breaker, its just a matter of updating places where I call for (regular most standard) screen measures to use dots apple understands. (converting raw pixels to framebuffer)

But linux also understands both ways... so it doesn't break anything. The problem (for me without a mac) is finding all those (numerous) calls to convert them. I went thru the pipeline and updated all major window and imgui creators, but smaller setters might still need to be update...

[surtarso]

you said you changed settings (to hide dmd for example) but it still showed up?
the new build tries to fix pathing too, so you probably changed the wrong settings file, sorry about that! =D

[herrMirto]

Yeah, if you don't have a Mac it would be really tricky. I can try to have a look into the code and see if I make any progress. If you look the second screenshot, it's crazy that the imgui is not even rendering anything. I won't open any issues or anything like that, maybe we just keep the discuss here and if me or you have something new to share, we just message each other.

But THANK you very much already!!

[surtarso]

So I was looking at the code to wonder why your tiny editor became a tiny gray screen and it clicked... I added manual scaling on new_frame() so the scaling was happening every frame so things were getting bigger and bigger at runtime.. thus a gray screen only lol

I well.. think I fixed it by moving that logic to initialize()....

so MAYBE, the editor will now render properly.

Sucks that I can't even see squiggles from typos inside ifdef APPLE blocks so a mistake is bound to happen =P I'm solely relying on the github workflow cmake output to find errors.

Did you get to try the workflow artifact after I (may have) fixed the pathing issues? it should not try to write inside .app anymore and fix the "broken package" deal.

[surtarso]

It really seems to be a simple 'point vs pixel' deal only to get imgui just right.
And linux doesnt care if its pixel or points so it's just a matter of finding those spots and converting the calls....

most changes are in core/window_manager (for FE windows) and core/ui/imgui_manager (for all app's imgui control, both editor and FE)... and maybe the bootstrap() in main.cpp, but it seems we shouldnt call DPI there and just let SDL handle HIDPI...

[herrMirto]

I might expand some time in the near future to look on that. I did some small changes, but none of them seems to have any effect.