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.

RE15pc v0.3.0 - Biohazard 1.5 (Nov 6, 1996) prototype

RE15pc v0.3.0 — Biohazard 1.5 (November 6, 1996)

A native Windows x64 build of the Resident Evil 1.5 prototype, produced by statically recompiling the disc's MIPS executable and its seven overlays with RecompOne. No emulator, no BIOS: the guest code is compiled to native code and runs on your GPU.

⚠️ You must supply your own disc

The archive contains no disc image and no Capcom art or audio. It cannot boot without Bio2Nov96.bin, which you have to provide. Put it next to RE15pc.exe with the included Bio2Nov96.cue, then run. The disc is verified by SHA-256, so a different image is refused rather than half-working.

The archive does contain the recompiled guest — a transcription of the disc's executable, compiled in. That is the one game-derived binary this project distributes, and it is stated plainly in NOTICE.

What's in it

Self-contained Windows x64 — carries its own .NET runtime, so nothing needs installing. Unzip and run.

RE15pc.exe	the host, with its icon and product metadata embedded
README.txt	the three lines you actually need
runtime + RecompOne + native libs	GLFW, cimgui, SDL2, OpenAL, native file dialogs

The .bin is deliberately excluded by tools/New-ReleasePackage.ps1, by name, so a release cannot start shipping the game by accident.

Display works at any resolution

Window geometry is derived from your monitor instead of hard-coded, and there is now a borderless mode that fills any screen without changing its resolution.

RE15pc.exe --window-mode borderless      fill the screen, no mode switch
RE15pc.exe --resolution 1920x1080        a specific window size
RE15pc.exe --window-mode fullscreen      exclusive fullscreen
RE15pc.exe --help                        everything else

Verified on a 3840×2160 panel at 150% scaling: first run opens at 90% of the work area, centred and on-screen; a requested 4000×3000 is clamped to fit instead of hanging off the edges; borderless fills the work area with no title bar. The old fixed 1280×720 opened partly off-screen on anything narrower, with a title bar you could not reach. 4:3 game content letterboxes correctly inside 16:9, ultrawide and portrait displays.

Xbox controllers work through XInput

Pads are read through SDL 2.30.8's game-controller API with the XInput backend explicitly selected, and the device path SDL reports (XInput#0 rather than a raw HID path) proves which driver took the pad. Bluetooth and other pads fall back to HIDAPI. Two pads, digital or analog, with per-device bindings and rumble.

Verify it on your own machine with your own pad:

pwsh -File tools/Test-GamepadBackend.ps1 -VirtualPad

Verified in this build

• Native acceptance harness PASS, including its negative controls (a silent-audio case, a timeout case and a refused non-empty output directory — it fails if any of them passes)
• Leon's first-room gate PASS: rooftop rendering, turning, world movement, railing collision with sliding, and a deliberate door transition into room 116, checked against the disc's own door record
• Elza's entry gate PASS: spawning in room 1031 with the previously missing callback and computed-copy suffix executing
• All 49 ordered overlay replacements; 166 focused checks; recompilation reproduces ten generated files byte-for-byte
• Controller and display claims above measured, not assumed

Known limits — read these

This is phase 2 of 5, and gold is not close.

• 294 of 334 disc files remain unverified. One encounter and two actors are covered, not the game.
• Save/load persistence is not implemented.
• Input is not fully certified: known synthetic arrow-event gaps fail acceptance rather than being swallowed.
• No stability gate: representative 30-minute sessions have not been run.
• Full room and scenario coverage, remaining interactions and enemy behaviour are open.

Synthetic dispatch success, nonzero audio, pixel counts and a clean smoke run deliberately do not count as playability here. See docs/phases.md for the authoritative status.

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. Repository contents are MIT licensed; see LICENSE and NOTICE.