"retroarch" activity kind #129
No reviewers
Labels
No labels
bug
duplicate
enhancement
future
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
albert/shepherd-launcher!129
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/retroarch-emulator-support"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes #125.
This provides a "retroarch" activity kind for content that can run within any of RetroArch's supported cores. Special considerations are made for:
Emulated games launched as plain `type = "process"` entries lose the child's progress: RetroArch only writes the in-game save and its resume state on a clean exit, and nothing arranges for one. The dedicated kind makes an emulator behave like every other supervised activity -- close saves, open restores, and the child cannot walk out of the game into RetroArch's file browser. [entries.kind] type = "retroarch" core = "mgba" content = "~/Games/retroarch/pokemon-firered.gba" `shepherd-host-linux::retroarch` renders the settings that need to hold into a config fragment passed with `--appendconfig`: per-entry save/state directories, save-state on close and restore on open, `autosave_interval` so the in-game save survives a crash, `pause_nonactive = false` (the HUD takes keyboard focus for its prompts), and kiosk mode. RetroArch sessions also get a longer graceful-stop floor, since their shutdown has to unload the core and write both kinds of save. The user's own `retroarch.cfg` is never edited. That takes an explicit setting to guarantee: `config_save_on_exit` defaults to *true*, so a clean exit would otherwise write RetroArch's whole live settings block -- everything we appended included -- back into it, making per-activity choices permanent and global. Core names are resolved against the files actually present rather than a filename computed from the name, because the two disagree for most cores: `genesisplusgx` ships `genesis_plus_gx_libretro.so`, `mupen64plus-next` ships `mupen64plus_next_libretro.so`, and the ten Beetle cores are libretro's Mednafen forks. Of 87 packaged cores, 74 match by name and 12 need the alias table; both sets are covered by tests built from the package contents. `content` must be absolute or `~/`-prefixed: a bare relative path resolves against the daemon's working directory, not the operator's, so it would fail at launch rather than at config validation. `SpawnOptions` gains `entry_id` so per-entry state can be keyed by it -- two entries pointing at the same ROM keep separate progress. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EmzB2jqPktJdFPNpg89h4Ma1cd67fda2b3656e34f2b3656e34f25217d7de9dView command line instructions
Checkout
From your project repository, check out a new branch and test the changes.