- Lines 4 indicates a simple build type, the simple build type is just executing the given `build-commands`, ie downloading and copying files rather than compiling and building the project. The preference is to compile and build emulators to support the Flatpak process in producing increased compatibly and customisation. Ruffle is a rust project and under constant development. It is hoped to make this a compiled project in the future.
- A simple project is also a good starting point to Flatpak builds.
- type: `archive`, this means that the archive is download and extracted without any explicit manifest action, `file` type source instead would just download the file without extracting it.
- url: obviously the url to download
- sha256: the sha256sum of the file, this is mandatory
> **NOTE:** In some rare cases we might don't know the sha (or even the url) in advance, for example when an emulator is having only one release on GitHub that is being kept updated without a release history.
[Guide: Automate emulator updates with placeholders](automate-emulator-with-placeholders.md) is explaining how to use the placeholders instead of urls or sha in case the this data cannot be foreseen.
Fort his purpose we have implemented an automation to get that data from the repository itself to being used only as a final resource as we prefer to control the version of each module for proper troubleshooting and version control.
Move you new yml code to just after key dependencies in the manifest. So that you do not have to wait until near the end of the build to check your manifest actions.
Not even ES-DE should be needed to test the additional emulator. In fact it will not show up in ES-DE. See [here for more.](#add-emulatorsystem-to-es-de)
If you run via self hosted it easier to track the build and any issues/errors are logged.
Other than human error with the code the most frequent issue is with sha256 issues due to issue with download or a version change. So there sha256 no longer matches.
If the build completes without errors it should produce an artifact that you can download and test
Generally, very few things would target the roms folder, but the other folders could be targeted for various scripts. Our recommendation would be to back up the full ~/retrodeck folder, but as a tester you can decide how much you want to risk.
`flatpak uninstall --user net.retrodeck.retrodeck` and press (y) yes to remove RetroDECK. If you have more then one version installed for some reason choose to remove all versions.
`flatpak uninstall --system net.retrodeck.retrodeck` and press (y) yes to remove RetroDECK. If you have more then one version installed for some reason choose to remove all versions.
Once cloned cd into your cloned directory and create a new branch and then
```bash
cd retrodeck-main/resources/systems/linux
```
There are two files in that folder and the relevant ruffle sections are shown below. There is a good chance that the emulator or system you are adding is already there and just needs to have the remarks removed. If not you can use this as an example of what needs adding.
In the rules file I added an entry for the ruffle-wrapper.sh and added the <!-- RetroDECK --> remark to make it easier to compare for differences when merges are made from ES-De source project. A wrapper script was required as ruffle has most options set from cli switches. The wrapper script is documented below.
Ruffle wrapper script sources the /app/libexec/global.sh to reference the $saves_folder variable. it also allows the use if check_desktop_mode function so that a different graphics preference can be set for Steam Deck in game mode.
