RE15pc v0.4.0 - no disc image needed at runtime

RE15pc v0.4.0 — no disc image needed at runtime

Everything in v0.3.0, plus the change that makes this feel like an installed PC game rather than an emulator pointed at a disc.

Import your disc once, then forget it

RE15pc.exe --import-disc path\to\Bio2Nov96.cue

That writes data\re15pc.disc beside the executable. From then on, no .cue, .bin or .chd is needed anywhere — just run RE15pc.exe:

[RE15pc] using the imported disc store at ...\data\re15pc.disc (no disc image needed)

The store is one compressed file holding the disc's track table and its raw 2352-byte sectors: 41 MB against a 124 MB disc, with no CD emulation left. --data <path> overrides the location; an explicit --cue still wins if you name a disc.

The import verifies itself

Every import re-opens the store it just wrote and compares every raw sector and every track entry against your disc:

[RE15pc] verified: all 52,849 raw sectors and every track entry match the disc

The store also records the SHA-256 of the sector stream it was built from, so validation afterwards is stronger than the cue path, not weaker: an imported installation proves it was built from the right disc without the disc being present, where a .cue build only checks the hash while the image is still on disk. A store built from a different image is refused with a message saying so.

Why it keeps raw sectors, and what "equivalent" means here

The CD layer is addressed in raw 2352-byte sectors, because that is how the guest streams XA audio and MDEC video — the sync, header, subheader and EDC/ECC bytes all have to come back exactly as they sit on the disc. A store built from extracted files cannot work: the bytes outside each file's data area would have to be reconstructed, and nothing in an ISO9660 listing records them. So the container changes and the data does not.

That gives a claim stronger than "it boots": the store is byte-exact at the data level. It matters that the claim is made there, because the port is not run-to-run deterministic in guest RAM — two runs of the same disc already differ in their RAM and VRAM dumps, so an end-to-end comparison cannot tell a store defect from that noise. A 2100-frame scripted run reaching STAGE1 was measured against both sources and produced byte-identical framebuffer readbacks.

⚠️ You still need your own disc — once

The archive contains no disc image, and no Capcom art or audio. The import is a one-way conversion of your disc on your machine; the store it produces is the entire game and cannot be turned back into an image, so it is gitignored, excluded from this archive, and not something to share. data\ is your install, nobody else's.

Also in this build

• Any resolution: window geometry is derived from your monitor, with a borderless mode that fills any screen without changing its resolution. --resolution WxH and --window-mode for the explicit cases.
• Xbox controllers via XInput, with the driver confirmed rather than assumed.
• Leon's first-room gate and Elza's entry gate pass; the native acceptance harness passes including its negative controls.

Known limits — unchanged, and worth re-reading

Phase 2 of 5. 294 of 334 disc files remain unverified; one encounter and two actors are covered, not the game. Save/load is not implemented. Input is not fully certified. No stability gate has been run. Synthetic dispatch success, nonzero audio, pixel counts and a clean smoke run deliberately do not count as playability here.

Not affiliated with Capcom

Unofficial, non-commercial preservation and research work. Resident Evil and Biohazard are trademarks of Capcom Co., Ltd. No Capcom code, art, audio, disc image or BIOS is redistributed. See LICENSE and NOTICE.