You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for the suggestion! An AppImage makes sense for Linux and we'll look at it. The main work is that the setup writes your game dump, the compiled game code, saves and settings next to the program, and an AppImage is read-only, so all of that has to move to a writable folder first. Is something not working for you with the current zip, or is it mainly about convenience (one file, desktop integration)?
Thanks for the suggestion! An AppImage makes sense for Linux and we'll look at it. The main work is that the setup writes your game dump, the compiled game code, saves and settings next to the program, and an AppImage is read-only, so all of that has to move to a writable folder first. Is something not working for you with the current zip, or is it mainly about convenience (one file, desktop integration)?
On standard linux systems the place to write this stuff to would be inside the users home folder.
~/.config/ZeldaWWHDRecomp
or
~/.local/share/ZeldaWWHDRecomp
going with any of these locations would be ideal.
the user has full permissions for these directories and anything inside ~/ which is just an alias for /home/some_user
appimages themselves are just more convenient, take less steps to setup compared to a zip file that has a bunch of loose files inside.
it also makes it easier to manage updates without having to repeat the process of getting everything setup again.
Basically you allow the user to store the appimage anywhere they feel like. The user then executes this appimage. Any writing for config files and similar will happen at a directory like ~/.config/ZeldaWWHDRecomp which is where such files are stored per app. Store any configs/generated assets here.
Thanks for the suggestion! An AppImage makes sense for Linux and we'll look at it. The main work is that the setup writes your game dump, the compiled game code, saves and settings next to the program, and an AppImage is read-only, so all of that has to move to a writable folder first. Is something not working for you with the current zip, or is it mainly about convenience (one file, desktop integration)?
Convenience, save data and config files could be saved to ~/.config/WWHDRecomp for example (or set by user in the WWHD settings stuff)
Done: PR #101 by @mhbxyz adds a single-file AppImage for Linux (x86_64 and aarch64) next to the zip, starting with the next release. Since an AppImage is read-only, it keeps the game, its compiled code, saves and settings in your user folders ($XDG_DATA_HOME/wwhd, usually ~/.local/share/wwhd); --data-dir picks another folder. On distros without libfuse2 (e.g. Ubuntu 24.04+), run it with --appimage-extract-and-run. The zip release stays as it is. Thanks everyone for the suggestions here!
Thanks @missionfloyd, good pointer! We kept the per-user folders as the default (that's the usual place for AppImages, and the AppImage's own folder isn't always writable), and added a simple portable mode using $APPIMAGE: if a folder named like the AppImage plus .data exists next to it (for example WindWakerHD-…-linux-x86_64.AppImage.data), the AppImage keeps the game, its code, saves, settings and caches in that folder. Without the folder nothing changes. It's in devel now and will be in the next release.
Thanks @missionfloyd, you're right: the AppImage runtime's own portable mode (<name>.AppImage.home, created with --appimage-portable-home) already covers this, since the game keeps its data under ~/.local/share/wwhd and ~/.config/wwhd. We'll drop our own .data folder before it gets released and document the standard way in the README instead.
A correction to my last comment: the .data folder had already shipped in v0.2.13, not only in devel.
The standard AppImage portable mode is now in devel and in the development build, and it will be in the next release: start the AppImage once with --appimage-portable-home, or create <name>.AppImage.home next to it. Our own .data folder is no longer used.
If you used ….AppImage.data with v0.2.13, move its contents before starting the new version:
Then start the AppImage once with --setup. If a .data folder is still next to the AppImage, the new version shows a hint about this. The steps are also in the release notes (CHANGELOG.md).
The issue stays closed; comment /reopen if something doesn't work.
Activity
lschaupp commentedon Oct 7, 2026
Thanks for the suggestion! An AppImage makes sense for Linux and we'll look at it. The main work is that the setup writes your game dump, the compiled game code, saves and settings next to the program, and an AppImage is read-only, so all of that has to move to a writable folder first. Is something not working for you with the current zip, or is it mainly about convenience (one file, desktop integration)?
xsoalokinx commentedon Oct 7, 2026
On standard linux systems the place to write this stuff to would be inside the users home folder.
~/.config/ZeldaWWHDRecomp
or
~/.local/share/ZeldaWWHDRecomp
going with any of these locations would be ideal.
the user has full permissions for these directories and anything inside ~/ which is just an alias for /home/some_user
https://docs.appimage.org/packaging-guide/index.html
^ relevant package guide for appimages.
appimages themselves are just more convenient, take less steps to setup compared to a zip file that has a bunch of loose files inside.
it also makes it easier to manage updates without having to repeat the process of getting everything setup again.
Basically you allow the user to store the appimage anywhere they feel like. The user then executes this appimage. Any writing for config files and similar will happen at a directory like ~/.config/ZeldaWWHDRecomp which is where such files are stored per app. Store any configs/generated assets here.
govt-boot-licker commentedon Oct 8, 2026
Convenience, save data and config files could be saved to ~/.config/WWHDRecomp for example (or set by user in the WWHD settings stuff)
Linux: bundle the release as one AppImage (issue ZeldaWWHDRecomp#55)
Linux: bundle the release as one AppImage (issue #55) (#101)
lschaupp commentedon Oct 9, 2026
Done: PR #101 by @mhbxyz adds a single-file AppImage for Linux (x86_64 and aarch64) next to the zip, starting with the next release. Since an AppImage is read-only, it keeps the game, its compiled code, saves and settings in your user folders (
$XDG_DATA_HOME/wwhd, usually~/.local/share/wwhd);--data-dirpicks another folder. On distros without libfuse2 (e.g. Ubuntu 24.04+), run it with--appimage-extract-and-run. The zip release stays as it is. Thanks everyone for the suggestions here!missionfloyd commentedon Oct 11, 2026
$OWDshould be the working directory when the appimage was run, or you can get the folder containing it from$APPIMAGE.https://docs.appimage.org/packaging-guide/environment-variables.html
lschaupp commentedon Oct 11, 2026
Thanks @missionfloyd, good pointer! We kept the per-user folders as the default (that's the usual place for AppImages, and the AppImage's own folder isn't always writable), and added a simple portable mode using
$APPIMAGE: if a folder named like the AppImage plus.dataexists next to it (for exampleWindWakerHD-…-linux-x86_64.AppImage.data), the AppImage keeps the game, its code, saves, settings and caches in that folder. Without the folder nothing changes. It's indevelnow and will be in the next release.lschaupp commentedon Oct 11, 2026
Closing the issue for now. Let us know if you have a follow up on this and reopen it.
missionfloyd commentedon Oct 12, 2026
You don't actually have to do anything for that to work, Appimages do it on their own.
https://docs.appimage.org/user-guide/portable-mode.html
AppImage: portable mode with a <AppImage>.data folder (ZeldaWWHDRecom…
lschaupp commentedon Oct 12, 2026
Thanks @missionfloyd, you're right: the AppImage runtime's own portable mode (
<name>.AppImage.home, created with--appimage-portable-home) already covers this, since the game keeps its data under~/.local/share/wwhdand~/.config/wwhd. We'll drop our own.datafolder before it gets released and document the standard way in the README instead.AppImage: a hint when a v0.2.13 <image>.data folder is still there (#55)
AppImage: use the runtime's standard portable home instead of .data (#55
Changelog: AppImage standard portable mode, moving a v0.2.13 .data fo…
AppImage: a hint when a v0.2.13 <image>.data folder is still there (#55)
test_appimage_apprun: skip on Windows (AppRun is a Linux script; MSYS…
AppImage: use the runtime's standard portable home instead of .data (#55
Changelog: AppImage standard portable mode, moving a v0.2.13 .data fo…
AppImage: a hint when a v0.2.13 <image>.data folder is still there (#55)
test_appimage_apprun: skip on Windows (AppRun is a Linux script; MSYS…
lschaupp commentedon Oct 12, 2026
A correction to my last comment: the
.datafolder had already shipped in v0.2.13, not only indevel.The standard AppImage portable mode is now in
develand in the development build, and it will be in the next release: start the AppImage once with--appimage-portable-home, or create<name>.AppImage.homenext to it. Our own.datafolder is no longer used.If you used
….AppImage.datawith v0.2.13, move its contents before starting the new version:….AppImage.data/share→….AppImage.home/.local/share….AppImage.data/config→….AppImage.home/.config….AppImage.data/cache→….AppImage.home/.cacheThen start the AppImage once with
--setup. If a.datafolder is still next to the AppImage, the new version shows a hint about this. The steps are also in the release notes (CHANGELOG.md).The issue stays closed; comment
/reopenif something doesn't work.