Mushihimesama Futari for Linux

This is my fork of ChanseyIsTheBest/futari-nx, the native Nintendo Switch port of the Xbox 360 version of Mushihimesama Futari Ver 1.5 (CAVE, 2009). It adds a native Linux build for AArch64 and x86-64, with the Black Label and Ver 1.01 downloadable content.

Chansey's project already handled the bulk of the work. The game's PowerPC code (default.xex and its eight game cores in media/Module/*.xex) is statically recompiled to C++ with ReXGlue, and its Direct3D-level renderer draws the game's Direct3D calls directly. Because that port already runs on an ARM processor, its AArch64 code carries straight over to ARM Linux handhelds. On Linux the renderer runs on Vulkan through plume instead of deko3d. Nothing is emulated and the game runs without a container.

I built and tested it on an ARM handheld running Armada (Adreno with Mesa Turnip), compiled inside a Fedora toolbox and launched natively from Steam Game Mode. The x86-64 build (linux-amd64 preset) is tested on a laptop with an NVIDIA GPU on KDE Plasma Wayland at 240 Hz and on an AMD handheld.

The Linux changes are also offered upstream in ChanseyIsTheBest/futari-nx#2. For the Switch version, use upstream and its installer page.

Note

You need your own copy of the Xbox 360 disc, either a disc image (.iso) or a folder you extracted it into. The Black Label and Ver 1.01 DLC packages (Content/<profile>/435A07D7/00000002) are optional.

Note

I am working on an English translation patch for the parts of the game that are still in Japanese: menu descriptions, option help, and the replay, storage and leaderboard messages.

FAQ

Windows/macOS?

Not supported by this fork: it is built and tested on Linux only (x86-64 and AArch64). The source still contains upstream futari-nx's Windows PC build (docs/building.md), untouched and untested here. springah/futari_recomp builds Futari for Windows and macOS with the SDK's emulated GPU, and upstream futari-nx builds for the Nintendo Switch and Windows.

Is this a native port?

Yes, for the game code and the graphics. The PowerPC code of default.xex and the eight game cores is recompiled ahead of time into C++ and runs directly on the processor, with no CPU emulation or JIT, and a Direct3D-level renderer draws the game's Direct3D calls with Vulkan through hedge-dev's plume, with no Xbox 360 GPU emulation. The game mixes its own audio, and the Xbox kernel and XAM calls are Xenia-derived reimplementations in C++.

Is this AI slop?

Mostly no. The vast majority of this project is code ported and retooled from other recompilation projects, such as UnleashedRecomp with hedge-dev's plume and XenosRecomp (the Vulkan layer, the shader translation, frame pacing, window icon), springah's futari_recomp (exit from the title screen) and SDOJ-Recomp (a reference for the input-lag work), along with, of course, existing Futari projects like futari-nx and springah's futari_recomp, tailored for Futari on Linux. LLM assistance was used in the porting, but under strict supervision and guidelines and with all changes rigorously reviewed and tested. As an example of what I mean by "assisted", I wrote/ported most of the Linux-side input latency code myself, then ran it through an LLM to improve, debug, fed it back to me to review, tweak and test, and so on.

Quiver Launcher once again, without my knowledge, switched their tag from AI-assisted, which accurately describes my work on this port, to mostly AI, even though they had already changed it. This is not accurate. Instead of making their tag accurate, they've inexplicably removed it, despite accepting it to begin with. Don't know what the fuck they're doing over there, but whatever.

There is also a strict no machine generated media rule, so you will never see slop generated "art" (generated slop is not art) or media in regards to any project I administer.

Does this port reduce input lag?

Yes, it is the main goal of this fork, and it is on by default: the game reads the pad as late in its frame as it safely can, its vertical blank follows the display's refresh, and vsync is off by default. On a laptop with an NVIDIA GPU on KDE Plasma Wayland at 240 Hz I measured 4.7 to 6.3 ms on average from pad read to present, with vsync off. The details are under "Input latency" below.

What does futari_vblank_display_sync do?

It is on by default, and it is not vsync. Vsync (renut_vsync, off by default) decides whether a finished picture waits for the display's next refresh. futari_vblank_display_sync decides when the game starts each frame: the game's 60 Hz vertical blank (where it reads the pad and starts the frame) follows the display's real refresh instead of a timer of its own that drifts against the display. The refresh is worked out from when pictures appear on screen with Vulkan's VK_KHR_present_wait. A display at a whole multiple of 60 Hz (60, 120, 180, 240 Hz) is followed. At any other rate, without present wait, or where the times do not follow the display (a desktop's Xwayland), the game keeps its 60 Hz timer and the log says so. The game still runs at 60 frames a second either way. On a 60 Hz display the vertical blank also waits for the previous picture to be shown (futari_vblank_wait_shown), so no picture stays queued after a stall. The 4.7 to 6.3 ms above was measured with it on.

Can this help with other CAVE games?

It already has: Espgaluda II recomp uses this renderer port and its input-lag work. Other CAVE games on the Xbox 360 could start from it too, alongside SDOJ-Recomp.

Installing

1. Download futari-linux-x86_64.tar.gz (PCs, laptops, x86-64 handhelds) or futari-linux-aarch64.tar.gz (ARM handhelds) from Releases and extract it wherever you keep games. Running uname -m in a terminal on the device prints x86_64 or aarch64. Quiver installs it the same way.
2. Add your game, one of two ways:
   • Disc image: put the .iso next to the futari program. The first start extracts it into game_root (a window shows the progress), after which the ISO can be deleted.
   • Extracted files: copy them into game_root (default.xex and the media folder at its top).
3. Optional DLC: put the Black Label and Ver 1.01 packages in dlc. The game installs them at its next start.
4. Start futari. To play from Steam, add futari as a non-Steam game and start it from Game Mode.

Updating is the same download: extract it over the old folder. game_root, dlc and the saves (in ~/.local/share/futari) stay. futari.toml is replaced, so copy it first if you changed settings.

No game files are included. The game's shaders are translated for Vulkan and built into the program, as other recompilation projects do.

The installer page still works, for the 1.1.0 build.

Building

The whole process, with the packages for Arch Linux ARM and Fedora, is in docs/building-linux.md. Build on the machine that will run it, since the code generator and the shader tools run on the host during the build.

From a disc image

tools/linux/build.sh --iso "/path/to/Mushihimesama Futari.iso"
tools/linux/package.sh

From a folder you already extracted the disc into (default.xex and media/ at its top)

tools/linux/build.sh --game-dir "/path/to/the/folder"
tools/linux/package.sh

Codegen takes about an hour and every step is skipped when its output already exists, so the script can be run again after a failure. Each generated file can take 1 to 2 GB to compile, so on a handheld pass --jobs 4 or --jobs 8 if the build gets killed. On AArch64 you also need DirectXShaderCompiler (dxc), which Fedora does not package. The docs show how to build it once. On x86-64 the prebuilt one in the tree is used.

package.sh puts everything in one folder (out/futari-nx-linux-arm64/ or out/futari-nx-linux-amd64/)

futari          the executable
*.so            the SDK runtime, the GPU plugin and the eight game cores
futari.toml     your settings
game_root/      the files of your disc
dlc/            optional Black Label and Ver 1.01, installed by the game at its first start

Run ./futari from that folder. To add it to Steam, add futari as a non-Steam game and start it from Game Mode.

Input latency

Low input lag was the main goal. The Switch port's work carries over (the game reads the pad as late in its frame as it safely can, and a two-image swapchain shows the newest picture). The parts that were Switch-only got a Linux version.

• The game's 60 Hz vblank follows the display's real refresh. Linux has no vsync event for a window, so the refresh is worked out from when frames actually appeared on screen, using Vulkan's VK_KHR_present_wait. A 60, 120, 180 or 240 Hz display is followed. Without present wait, or at any other rate, the game keeps its 60 Hz timer and the log says so.
• input_sdl_sync_poll (on by default) updates the gamepads on the thread that reads them, right before each read. Before, a read got the state from the last UI-thread pump, which could be a whole frame old.

The details and the related settings are in the "Input latency" section of docs/building-linux.md.

Settings

futari.toml next to the executable holds your options. Any setting can also be given on the command line as --name=value.

Setting	Linux default
futari_renderer	"renut"
renut_gpu_backend	"vulkan"
fullscreen	true (set false for a window)
log_level	"warn"
input_sdl_sync_poll	true

On a Wayland desktop (KDE Plasma 6.7 and others with the fifo-v1 protocol) the game runs as a native Wayland window; elsewhere through X11, and under gamescope through gamescope's XWayland. SDL_VIDEO_DRIVER=x11 forces X11. On a screen that is not 16:9 the picture keeps its shape with black bars (futari_fill_crop = true fills the screen and trims the edges instead). Press F4 in the game for the settings window (this game's settings by category, search box, "Save to config"); every setting, with its default and what it does, is in docs/settings.md. On the title screen, B on a pad or Escape on the keyboard (bind_title_exit) quits the game. On handhelds whose built-in pad is managed by InputPlumber or Steam Input, launch it from Steam Game Mode so the controller shows up.

What changed from upstream

• CMake presets linux-arm64 and linux-amd64 (clang, Ninja, Vulkan) and a Linux settings template.
• The eight game cores built as shared libraries next to the executable, loaded by file name.
• FUTARI_RELEASE_FORMS, on by default on Linux AArch64, so the generated code uses the same forms as the Switch build.
• A system dxc and libdxcompiler on AArch64 hosts, since there are no prebuilt ARM64 Linux ones.
• The display-locked vblank and the synchronous SDL pad polling described above.
• tools/linux/build.sh, codegen.sh and package.sh, and docs/building-linux.md.
• Release builds without the game's shaders (build.sh --release, package.sh --release). They read vulkan_spirv.bin from their own folder, which the installer page makes.

The Windows and Switch builds are untouched. For the port itself (every optimisation, the renderer, audio, and how each change was checked) see upstream's README and docs/futari-notes.md.

Credits

• CAVE created Mushihimesama Futari. This is an unofficial, fan-made port with no affiliation.
• ChanseyIsTheBest made the Switch port this fork is built on. Everything outside the Linux changes is that work and the work it credits.
• Tom Clay made the ReXGlue SDK, built on the work of the Xenia team.
• plume (from UnleashedRecomp) is the graphics layer the renderer draws with.
• hedge-dev made XenosRecomp, the Xenos shader translator.
• SDOJ-Recomp served as a reference for the Linux input-latency work.
• The full upstream credits and the other libraries are in upstream's README and THIRD_PARTY_NOTICES.md.
• Linux port by cerroverb.

Legal

No affiliation with CAVE or Microsoft. "Mushihimesama Futari" is a trademark of CAVE Interactive. This repository contains no assets or program code from the original game. You must provide your own legally obtained copy, and everything made from it (assets/, app/generated/, the shaders) is made on your own computer.

Source code is provided under the GPL-3.0 License (see LICENSE), like the ports it builds on. The SDK keeps its BSD-3-Clause license (see THIRD_PARTY_NOTICES.md).