Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue 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

Đang mở
  • Có gì không ổn?
#1,265 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
70/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
cpp, javascript, wasm
Lĩnh vực
frontend, tooling

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
JavaScript
Star
4.3k
Fork
1k
Merge trung bình
13 ngày 2 giờ
Pull request đã merge (30 ngày)
3

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của EmulatorJS/EmulatorJS

Tất cả issue của EmulatorJS/EmulatorJS

Issue tương tự

Thêm issue về JavaScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.