Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

[Feature] DOSBox Pure saves: expose the core-written .pure.zip to getSaveFile()/saveSave (core has no SRAM), and don't extract the zip by default

Ouverte
  • Quelque chose ne va pas ?
#1,265 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
70/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Calme
Stack technique
cpp, javascript, wasm
Domaine
frontend, tooling

Piste de recherche

Start with data/src/emulator.js, especially the EJS_dontExtractRom and dontExtractIfCore handling, then trace getSaveFile(), getSaveFilePath(), and the saveSaveFiles/saveSave events. The issue identifies dosbox_pure_libretro.cpp and the existing PR #1064 as the relevant core and save-path context. Verify that DOSBox Pure is added to the non-extraction defaults and that a core-written .pure.zip is returned with its path; no specific test file is mentioned.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Summary. With dosbox_pure, a game's own in-game save never reaches a frontend that collects saves through gameManager.getSaveFile() (RomM does), because the core exposes no SRAM and the save it does write is not on the path getSaveFile() reads. Two small things would fix it; one of them is already on main and unreleased.

What happens (measured on 4.2.3, dosbox_pure, a zip with a root AUTORUN.CONF doing mount c .)
  1. downloadRom() decompresses the archive into the emscripten FS and hands the core one member — in 4.2.3 only ["arcade", "mame"] skip extraction, and this.fileName comes out as AUTORUN.CONF.
  2. Because the content extension is conf, DOSBox Pure skips its union-drive/save machinery entirely — dosbox_pure_libretro.cpp:2710-2712: 
    // Loading a .conf file behaves like regular DOSBox (no union drive mounting, save file, start menu, etc.)
dbp_skip_c_mount = (path_extlen == 4 && !strncasecmp(path_ext, "conf", 4));
    so the game writes its save straight into the extracted tree in MEMFS (King's Quest VI wrote /KQ6SG.000), which is gone with the tab. A save state does not carry it back: loading the state in a fresh tab, the file is absent and the game's restore dialog is empty.
  3. The core has no SRAM at all — dosbox_pure_libretro.cpp:3839-3840 (same in the EmulatorJS/dosbox-pure fork): 
    void *retro_get_memory_data(unsigned id) { (void)id; return NULL; }
size_t retro_get_memory_size(unsigned id) { (void)id; return 0; }
    so RetroArch never writes save_file_path() (/data/saves/DOSBox-pure/AUTORUN.srm here), getSaveFile() returns null, and the saveSaveFiles / saveSave events hand the frontend null. RomM stores the four bytes null as the save.
What already exists on main

PR #1064 added EJS_dontExtractRom and the dontExtractIfCore list (data/src/emulator.js:349, still arcade/FBNeo/MAME only). Handed the zip, DOSBox Pure takes its union-drive path and writes changes to <content>.pure.zip in the libretro save directory (DBP_GetSaveFile(SFT_GAMESAVE)), which is /data/saves (IDBFS) — so on nightly the save at least survives per browser. That is unreleased; v4.2.3 is the latest release.

Feature request
  1. Let a frontend collect the core-written save file. When save_file_path() does not exist but the core has written a file into savefile_directory (for DOSBox Pure, <content>.pure.zip), have getSaveFile() return that file — or fire saveSaveFiles / saveSave with it — so frontends that persist saves server-side (RomM's EJS_onSaveSave) get real bytes instead of null. getSaveFilePath() would then name that file so the frontend knows the extension.
  2. Default dosbox_pure to not-extracted, i.e. add it to dontExtractIfCore, or document EJS_dontExtractRom as required for DOSBox Pure saves — today a frontend that does not know about it gets the extracted-.conf behaviour above.
  3. A release carrying #1064 would already improve things for everyone on 4.2.3.

Happy to test a nightly against RomM. For transparency: measured on my own instance; the write-up was drafted with Claude Code's help from those measurements.

Langage dominant
JavaScript
Étoiles
4.3k
Forks
1k
Merge moyen
13 j 2 h
PR mergées (30 j)
3

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de EmulatorJS/EmulatorJS

Toutes les issues de EmulatorJS/EmulatorJS

Issues similaires

Plus d'issues JavaScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.