Assets not loading for compiled binaries

[naithar]

Platform:
macOS 10.15.4 and iOS 13.6 (as part of #87)

Description:
While testing sprite sample I've encountered an issue running a compiled (not cargo run) binary.
Both macOS and iOS didn't show sprite if binary was run directly even if asset folder was next to binary.
Changing relative (?) path to full path using std::env::current_exe() fixed the issue for macOS, but didn't work for iOS.

Edit:

Running binary on macOS from console fixes the issue.
Running binary by double clicking on it does not. Placing assets at ~ directory fixes the issue.
Making an .app package and running it also results in empty scene.

Console output for std::env::current_dir() and std::env::current_exe():

Running in console (works out of the box):

cargo run
dir: /Users/naithar/Projects/my_bevy_game, exe: /Users/naithar/Projects/my_bevy_game/target/debug/my_bevy_game
loading untyped at assets/branding/icon.png
loading: Handle<Texture>(d5e86b7d-a8d4-4cf4-bbca-9ed16033dc08)
...
./my_bevy_game
dir: /Users/naithar/Projects/my_bevy_game/target/debug, exe: /Users/naithar/Projects/my_bevy_game/target/debug/./my_bevy_game
loading untyped at assets/branding/icon.png
loading: Handle<Texture>(a7fbd902-d958-4c6a-8919-5c69fb27e992)

Running by double clicking (requires moving assets to HOME folder):

dir: /Users/naithar, exe: /Users/naithar/Projects/my_bevy_game/target/debug/my_bevy_game
loading untyped at assets/branding/icon.png
loading: Handle<Texture>(95a6da42-d8a9-404c-8ac5-734ffdd88e02)

.app package (specifying full path worked):

dir: /, exe: /Users/naithar/Projects/my_bevy_game/target/debug/Godot.app/Contents/MacOS/Godot

iOS application (specifying full path didn't work loading by full path seems to be working, but it's not displayed due to some other problem):

dir: /, exe: /private/var/containers/Bundle/Application/02EF133B-F04C-47FE-A936-770F5757D494/BevyTest.app/BevyTest
loading untyped at /private/var/containers/Bundle/Application/02EF133B-F04C-47FE-A936-770F5757D494/BevyTest.app/assets/branding/icon.png
loading: Handle<Texture>(9d955d34-51cd-4b36-996d-bf866fd048ac)

load returns correct texture handle all the time, even if there is nothing to load.

[Xavientois]

I am unable to reproduce this issue (running macOS 10.14.2). I did cargo run and it worked. Then, I copied the compiled binary into the project directory and it still worked. Finally, I tried just copying the binary and the assets folder into a separate directory and ran it. It did not work when I ran it from outside that directory, but it did work when I ran it from within that directory.

What is happening in my case is that the binary attempts to access the relative path from the working directory that the binary was called from, not necessarily where the binary is located. That would explain why std::env::current_exe() worked for you.

Could this be what is going on?

[naithar]

@Xavientois thanks :)
Strange, I tried that too, but it didn't work.
Did you run binary from console?

Also while moving assets from folder to folder or specifying direct path worked for macOS, it didn't work for iOS.

Maybe it's 10.15 issue specifically.

[naithar]

Updated description with more info and logs.

[naithar]

Adding std::env::set_current_dir(std::env::current_exe().unwrap().parent().unwrap()); at the start of the app works as workaround for compiled binaries for both macOS and iOS.

[MichaelHills]

Running from console works as expected, in that assets are relative to the current working directory. It might be nice to be able to provide a base dir for the asset loader (haven't checked if this is already supported). Especially for iOS, although I'm sure we can figure out the right way to drop in asset directories to xcode so that it works with the default path.

Packaged games is a different matter... on windows with your installer you could just setup the shortcut with the correct working directory. I don't know how to make a mac .app bundle. I haven't used linux desktop in a long time to know what the current state is there.

I suppose that iOS is special here in that the development build setup is already the packaged build.

[MichaelHills]

Stumbled across this https://agmprojects.com/blog/packaging-a-game-for-windows-mac-and-linux-with-rust

Sounds like you are on to something with the current_exe() suggestion, though not ideal for dev builds with cargo run.

Perhaps the answer is per-OS config switch or different config when bundling to set the asset base path?

[j1m-ryan]

I am also having this issue but on windows 10. Cargo run works perfectly in all the examples however I am having issues with cargo build (and cargo build --release). Some of the compiled binaries such as 3d_scene and spawner do load assets correctly but the 2d ones like sprite do not.

[naithar]

I am also having this issue but on windows 10. Cargo run works perfectly in all the examples however I am having issues with cargo build (and cargo build --release). Some of the compiled binaries such as 3d_scene and spawner do load assets correctly but the 2d ones like sprite do not.

3d_scene and spawner doesn't load anything with asset_server.load, so it's not a surprise.
Does adding std::env::set_current_dir(std::env::current_exe().unwrap().parent().unwrap()); at the start of main help you?

[j1m-ryan]

3d_scene and spawner doesn't load anything with asset_server.load, so it's not a surprise.

Ah okay! haha, should have realized that tbh! Cheers!

Does adding std::env::set_current_dir(std::env::current_exe().unwrap().parent().unwrap()); at the start of main help you?

No unfortunately not. Using std::env::set_current_dir(std::env::current_exe().unwrap().parent().unwrap()); for me causes assets not to load with cargo run and not to load with the cargo build binary either. Using std::env::current_exe().expect(""); results in the same behavior as before where the assets load with cargo run but do not load in the binary.

[naithar]

If you use std::env::set_current_dir(std::env::current_exe().unwrap().parent().unwrap()); you should place assets at the same folder as executable - somewhere like target/debug, since that would be a folder where bevy will be searching for assets. You can probably just print working directory, so you wouldn't have to guess where to put it :)

[j1m-ryan]

Thank you @naithar that worked.

[naithar]

Fixed by #693
assets folder should be placed next to the compiled binary. For iOS assets folder should be listed in Copy bundle resources phase.

[Kage-Yami]

Stumbled across this https://agmprojects.com/blog/packaging-a-game-for-windows-mac-and-linux-with-rust

Sounds like you are on to something with the current_exe() suggestion, though not ideal for dev builds with cargo run.

Perhaps the answer is per-OS config switch or different config when bundling to set the asset base path?

For anyone else that stumbles upon this in future and is interested in the link (even if it's not needed for Bevy anymore), then this is a fixed link (as at today, at least; the original is missing .html on the end): https://agmprojects.com/blog/packaging-a-game-for-windows-mac-and-linux-with-rust.html