v1.5.2 — shell codegen fatal eliminated

Source + bundle release clearing the README's last known issue. Bundles for all three platforms were restaged from this tag the same day the repository went public; the Steam Deck build was boot-verified on the device.

• The shell's only codegen fatal is gone. The long-standing known issue — a split block at 0x82081778 whose branch back into sub_82081658's loop could not be expressed — rested on a pointer-scan false positive: the only pointer to that address in the whole image is a lwz r16,0x1778(r8) instruction whose encoding aliases the address. The address is now declared a chunk of its parent in futari_functions.toml, and the vendored SDK's half-built chunk mechanism was completed to honour it: a chunk claims its range (suppressing the PDATA, exception-handler, gapfill, and pointer-scan paths from re-splitting it) without emitting a function, a dispatch entry, or the fatal. The scans warn when they skip a chunk-claimed address, so a genuine dispatch table pointing at a chunk would surface rather than vanish. The generated shell changes by exactly one removed function; boot-verified with all 8 modules registering cleanly.

See CHANGELOG.md for details.

v1.5.1 — console-install extraction, ISO fix, macOS tag fix

Source + bundle release, cut mid-test-week so the new extraction route can be tested. Bundles for all three platforms were restaged from this tag the same day (Windows exe and Deck binary rebuilt — version stamps 1.5.1, SDK stamps verified v0.9.3.1 across shipped components; macOS app rebundled). The Windows and Deck F&F bundles now include the extraction tooling.

• The extractor now reads console disc installs directly — no god2iso, no Velocity. Copy the game's Content\...\435A07D7 folder off your console and drag it onto extract_assets.bat: the copy is verified against the container's own SHA-1 hash tree before extraction (a corrupt copy is refused with the exact file named), and any marketplace DLC packages found beside the install are validated and installed into dlc/. Validated against a real console install: all 9 executables match the DUMPING.md checksums; the tree is byte-identical to a disc rip's.
• ISO extraction produced garbage for every file; fixed. Reads were based at the volume descriptor's offset, but XDVDFS sectors are partition-relative — 32 sectors late for every file, since the first release. Working dumps historically came from the extract-xiso tooling this repo once vendored.
• macOS builds from the tag work again. The vendored SDK's VERSION file collided with C++'s #include <version> on case-insensitive APFS; renamed REXGLUE_VERSION. This is the first tag that builds clean on macOS as checked out.

See CHANGELOG.md for details.

futari v1.5.0 — family & friends test round

• Bundles gain gamecontrollerdb.txt — the community
  SDL_GameControllerDB
  (Zlib licence, snapshot 629ccc7, 2,254 mappings, tracked at
  dist/gamecontrollerdb.txt). The SDL input driver loads it from beside the
  exe, adding recognition for gamepads SDL3 doesn't know natively, and the
  startup warning about the file being absent goes away. Listed in
  THIRD-PARTY-NOTICES.txt.

• The SDK is vendored. thirdparty/rexglue-sdk is no longer a submodule
  pointing at a private fork — the tree itself is in the repo, taken verbatim
  from the fork at v0.9.3.1 (see thirdparty/rexglue-sdk/VENDORED.md for the
  documented deviations). A public clone now resolves every dependency.

• One ini again. v1.4.2 split the overlay's save target into
  futari_cvars.ini because the SDK's save was a truncating flat rewrite. The
  save now goes through a merge writer: F4's "Save to config" updates the
  friendly lines in futari.ini in place (comments and [Storage] intact) and
  keeps any other overlay-modified cvars in a marked block at the top of the
  file. A leftover futari_cvars.ini is loaded once at startup and parked as
  .bak. The write is temp-file + rename, so a crash mid-save cannot truncate
  the file.

Known issue building this exact tag on macOS: the vendored SDK's VERSION file collides with C++20's #include <version> on case-insensitive filesystems. Fixed on main immediately after the tag (file renamed REXGLUE_VERSION); the macOS bundle is built from that commit. Windows and Linux are unaffected.

v1.4.2 - build from this one (licensing, ini and extraction fixes)

Source release. No renderer or game-logic changes, so the v1.4.1 bundles remain current for players until these fixes are packaged. This is the tag to build from — v1.4.1 predates the macOS/Deck packaging fixes and the licensing files.

No game data is distributed — no disc image, no game executable, no media/, no audio. You supply all of it from a copy you own; see docs/DUMPING.md for the checksums to verify your dump against. The two game-derived files in this repository — the title screenshot and the application icon — are there for identification and are named in NOTICE.md, which also states what the licence does not cover.

Two bugs worth a rebuild

The in-game settings overlay no longer destroys futari.ini. The SDK defaults its own cvar file to <exe>/futari.ini — the same file the game reads and the player edits — and F4's "Save to config" rewrote it as a flat cvar list with a truncating write. [Storage] went with it, and because user_data_path is not a cvar, saves silently relocated to Documents\futari on the next launch. RUN.txt tells the player to press F4. The SDK now gets its own futari_cvars.ini.

extract_iso.py no longer reports a truncated extraction as success. The write loop broke on a short read, then logged the size from the directory table rather than the bytes written, and exited 0. A split or aborted rip produced empty files, a green log, and a confusing codegen failure hours later — the likeliest support case in this project, arriving disguised as a codegen bug. It now names each truncated file, exits non-zero, and rejects directory entries whose names would write outside the output directory.

Quoted paths in futari.ini also work now (user_data_path = "D:\Futari Saves"), matching the SDK's own parser for that file.

Licensing

THIRD-PARTY-NOTICES.txt is new, generated by scripts/gen_third_party_notices.sh and shipped inside bundles. The runtime statically links FFmpeg and libmspack, both LGPL-2.1, which obliges a written offer of source and relinkable objects — there was none — and ~20 permissive components had no notice either. A bundle's entire legal content was two lines of RUN.txt. macOS bundles now also carry MoltenVK's Apache-2.0 licence, and the build fails rather than omitting it.

NOTICE.md previously granted BSD-3 over all of src/, which included the game's own artwork in src/futari.ico. The icon is now carved out explicitly, and the claim that this repository contains "no game code, data, or assets, and never will" has been replaced with what is actually true, everywhere it appeared.

Other

Visual Studio Build Tools is named in the README prerequisites — clang-cl targets the MSVC ABI, so a clean Windows box with only LLVM fails on vcruntime.h, which was the first wall for anyone building this from scratch. The shell scripts have their executable bit. PORTS.md records what a bundle may contain, with the licence rule alongside it.

Building

GitHub's generated source archives do not include submodules, so clone the tag instead:

git clone -c core.symlinks=true --recurse-submodules -b v1.4.2 https://github.com/springah/futari_recomp

Mushihimesama Futari and all of its content are the property of Cave Interactive Co., Ltd. This project is not affiliated with or endorsed by Cave.

v1.4.1 - Windows, macOS, Steam Deck (SDK v0.9.3.1)

Static recompilation of Mushihimesama Futari (Xbox 360) for native PC, on ReXGlue SDK v0.9.3.1. These are the bundles players currently have.

No game data is distributed — no disc image, no game executable, no media/, no audio. You supply all of it from a copy you own; see docs/DUMPING.md, which lists checksums to verify your dump. The source archives below do contain two game-derived files (the title screenshot and the application icon, both for identification), and a built bundle necessarily contains the game's own program code, recompiled — which is why bundles are distributed only to people who own the game and are not attached here. See NOTICE.md.

Platforms: Windows, macOS (arm64), Steam Deck / Linux (x64).
Status: title, menus, audio, controller, and saves work; all 8 game modes load, run, and mode-switch cleanly. Deeper gameplay can still hit rare recompiler edge cases.

⚠️ Read this before building from the v1.4.1 tag

The tag marks the Windows release point only. The macOS and Steam Deck bundles were built from commits after it, so this tag does not contain their packaging fixes:

• b09b9aa — the Deck launcher and futari.ini fixes
• a99d3e6 — the macOS GPU-plugin staging and the mismatched-runtime fix

The tag also predates this project's LICENSE, NOTICE.md and THIRD-PARTY-NOTICES.txt. If you want to build the port, use v1.4.2 or main, not this tag. v1.4.2 is the same code with those fixes, the licensing files, and two bug fixes.

What was in v1.4.1

All three platforms rebuilt on SDK v0.9.3.1 (up from v0.9.2). An A/B of the two runtimes showed no behaviour change for futari — the value here is in the packaging, where each platform had a real defect.

Windows — bundle no longer ships development leftovers: ~64 MB of superseded binary backups, an instrumented reference exe, the Tracy profiler DLL, 212 of the developer's own run logs, and a machine-local shortcut. Packed under a proper top-level folder with standard forward-slash entries.

Steam Deck / Linux — three defects in the v1.4.0 bundle, all fixed:

• The launcher only worked from one directory. It hardcoded the absolute path it was tested from, so extracting the zip anywhere else could not start the game. It now resolves its own location.
• The shipped runtime was the wrong build — librexruntime.so identified as rexglue-v0.8.3 against a v0.9.0-dev binary and a v0.9-only GPU plugin. Every component now comes from one v0.9.3.1 build.
• The zip lost Unix file modes and used backslash separators, so the launcher arrived non-executable. Packed with zip -X now.

macOS — broken before v1.4.1; rebuilding is what surfaced it:

• The GPU plugin was never staged into the bundle. SDK v0.9 split the renderer out of the runtime, but mac-build/build_app.sh predated that split, so the app started and died with Failed to load GPU plugin 'xenos'. v1.4.0 shipped this way — macOS had no working renderer since the v0.9 migration. The plugin is now staged, deliberately renamed .dylib → .so, because the SDK's PluginFileName() asks for .so on every non-Windows platform including macOS. That rename is a workaround; the real fix belongs in the SDK.
• The bundle shipped a mismatched runtime. The script preferred $REXSDK_DIR over the pinned submodule, so a v0.8.5.1 librexruntime.dylib landed beside a v0.9.3.1 executable and dyld refused to launch it. The submodule now wins, and the build fails outright if executable and runtime report different SDK versions.

Mushihimesama Futari and all of its content are the property of Cave Interactive Co., Ltd. This project is not affiliated with or endorsed by Cave.