Ebitengine changes working directory when you have resources? about ebiten HOT 5 OPEN

Now the printed working directory is to the executable/resources.

Could you write the result? What are the results in init and main?

from ebiten.

I couldn't reproduce the issue

% go run .
init wd /Users/hajimehoshi/test/test
main wd /Users/hajimehoshi/test/test
ebit key F1

% neofetch
                    'c.          [email protected] 
                 ,xNMM.          ------------------------------------- 
               .OMMMMo           OS: macOS 14.2.1 23C71 arm64 
               OMMM0,            Host: Mac15,6 
     .;loddo:' loolloddol;.      Kernel: 23.2.0 
   cKMMMMMMMMMMNWMMMMMMMMMM0:    Uptime: 46 days, 9 hours, 40 mins 
 .KMMMMMMMMMMMMMMMMMMMMMMMWd.    Packages: 77 (brew) 
 XMMMMMMMMMMMMMMMMMMMMMMMX.      Shell: zsh 5.9 
;MMMMMMMMMMMMMMMMMMMMMMMM:       Resolution: 1800x1169 
:MMMMMMMMMMMMMMMMMMMMMMMM:       DE: Aqua 
.MMMMMMMMMMMMMMMMMMMMMMMMX.      WM: Quartz Compositor 
 kMMMMMMMMMMMMMMMMMMMMMMMMWd.    WM Theme: Blue (Light) 
 .XMMMMMMMMMMMMMMMMMMMMMMMMMMk   Terminal: tmux 
  .XMMMMMMMMMMMMMMMMMMMMMMMMK.   CPU: Apple M3 Pro 
    kMMMMMMMMMMMMMMMMMMMMMMd     GPU: Apple M3 Pro 
     ;KMMMMMMMWXXWMMMMMMMk.      Memory: 3434MiB / 18432MiB 
       .cooc,.    .,coo:.
                                                         
                                                         

from ebiten.

Thanks for looking into it -- indeed,

go run .

works fine for me as well. My test app is named "res" and I hit the issue when I do

go build
./res

I simplified the test app above, but without the the ebiten import included my output is

init wd /Users/spaceblack/Documents/dev/go/res

and with it included my output is

init wd /Users/spaceblack/Documents/dev/go/res/resources

Been poking at the source -- I see
internal/glfw/cocoa_init_darwin_m has a function changeToResourcesDirectory but I'm not sure if it's getting triggered, I don't see what's calling glfwPlatformInit. If you have any pointers let me know and I'll look at it.

from ebiten.

I failed to reproduce this even with go build.

Been poking at the source -- I see
internal/glfw/cocoa_init_darwin_m has a function changeToResourcesDirectory but I'm not sure if it's getting triggered, I don't see what's calling glfwPlatformInit. If you have any pointers let me know and I'll look at it.

This logic should be intentional, though this should not happen when the binary is not in a .app directory. I was wondering why this happens in your environment.

glfw/glfw@7302f76

glfwPlatformInit is called at:

from ebiten.

Thanks much for the help, unfortunately I don't know anything about macOS dev but after reading up on bundles, so far one thing has caught my eye:

CFBundleGetMainBundle says

CFBundle creates a main bundle whenever it possibly can, even for unbundled apps.

That has certainly been my experience. As long as there is an executable and a Resources folder present (actually I've been using "resources"; I thought macOS was case sensitive but in this case it seems to be ignored) then the parent is identified as a bundle. The go run . command does not return a main bundle with a Resources folder because it is compiled and run from a temp directory without a resources folder.

Of course, none of that explains why you (and presumably everyone else) is not having this issue occur. But based on my reading of the docs, what is happening on my system seems reasonable. Unfortunately I don't see any details around what "creates a bundle whenever it possibly can." All I can find are the rules around bundles, which would seem to exclude my case, and that one line, which is broadly inclusive but not specific enough for me to say I'm seeing what should be correct behavior.

I have another Mac I might try this on, otherwise I can't think of anything to do but try to find more info around how CFBundleGetMainBundle() is working.

from ebiten.