CoopAllTheThings

Steam Remote Play Together (RPT) for any XInput game — without breaking DRM, achievements, or playtime.

Existing "donor game" tools (e.g. RemotePlayWhatever) copy a target game's files into a donor game's folder and rename the executable so Steam streams the target under the donor's appid. That breaks DRM-protected games, breaks achievements, and credits playtime to the donor.

CoopAllTheThings takes a different approach: the real game runs normally under its own appid (so DRM, achievements, and playtime all work), while a lightweight mirror app runs under the donor appid. The mirror presents a borderless window that is a live copy of the game's video + audio, and forwards the guests' input back into the real game. Steam's RPT captures the mirror window — so any XInput game becomes Remote-Play-Together-able.

See docs and the in-repo plan for the full design.

Architecture (target)

Concern	Mechanism	Where
Receive guest input	Steam Input / XInput (RPT delivers guests to the focused window)	coop_host.exe
Forward input to game	DLL injection + XInput hook (SafetyHook) — game sees only our pad	coop_hook.dll
Mirror video	Windows Graphics Capture first; IDXGISwapChain::Present hook as the low-latency upgrade	host (+ hook)
Mirror audio	WASAPI process-loopback capture of the game, re-rendered	coop_host.exe
Host ↔ hook IPC	Named shared memory (seqlock for input, shared D3D11 texture for video)	common/

Limitations

• Anti-cheat: the input path injects coop_hook.dll into the target game. Games protected by kernel-level anti-cheat (Easy Anti-Cheat, BattlEye, Vanguard, etc.) will detect the injected module and may kick the player or issue a ban. Such games are explicitly out of scope and unsupported — do not use CoopAllTheThings with them. The tool targets single-player and co-op/local-multiplayer titles without active anti-cheat.
• XInput only: the game must read controllers via XInput (the common case). DirectInput-only / RawInput-only games are not handled.
• Architecture match: the host and hook DLL must match the game's bitness. x64 is supported first; x86 support is a later phase (see the plan).

Status

Phase 0 — donor spike. ✅ Validated. coop_host.exe is a borderless D3D11 window with an ImGui overlay listing every controller it sees. Confirmed end-to-end: Steam RPT streams the window under a donor appid, and guest gamepads arrive (with correct slot assignment) as XInput.

Phase 1a — input forwarding + focus spoofing (current). The host injects coop_hook.dll; the DLL hooks XInput (via SafetyHook) so the game reads the forwarded controller state and only that state. The DLL also spoofs focus (hooks GetForegroundWindow/GetActiveWindow/GetFocus and subclasses the game window to swallow deactivation messages) so the game keeps running and polling while the tool holds the real OS focus — required because Steam RPT only captures the focused window. A hook→host status back-channel shows whether the hook is attached and how fast the game is polling it. The in-process hook_selftest validates the IPC + hook core without needing a game.

Phase 1b — video mirror (current). The host captures the injected game's window with Windows Graphics Capture and draws it letterboxed as its background, so RPT streams a live mirror of the game. See the test steps below.

Still ahead (scoped in the plan): a Present-hook capture path if WGC latency disappoints, audio (WASAPI process loopback), and x86 support.

Building

Requirements: Windows 10/11, Visual Studio 2022 (MSVC + C++ workload), CMake ≥ 3.21.

git clone --recurse-submodules <repo-url>
# or, if already cloned:
git submodule update --init --recursive

cmake -S . -B build -G "Visual Studio 17 2022" -A x64
cmake --build build --config Debug
# output: bin/Debug/coop_host.exe

Third-party dependencies (Dear ImGui, SafetyHook) are git submodules under third_party/; the Steamworks SDK is vendored manually there when wired. No vcpkg / package manager is used.

Phase 0: validating the donor-launch assumption

This is a manual test — it needs Steam, a second person (or second account), and a donor game that supports Remote Play Together.

1. Pick a donor game you own that supports Remote Play Together (check the "Remote Play Together" tag on its store page). The donor only needs RPT support; it is never actually played.

2. Launch the host under the donor's appid. Find the donor's appid (the number in its store URL), then run:

   "C:\Program Files (x86)\Steam\steam.exe" -applaunch <donorAppId> "D:\dev\CoopAllTheThings\bin\Debug\coop_host.exe"
   

   The borderless overlay window should appear and Steam should consider the donor "running" (green status / "Stop" button in the library).

   If the donor ignores the trailing path, set the host as the donor's Launch Options instead ("D:\...\coop_host.exe" %command% variants), or use a launcher such as RemotePlayDetached. Recording which method makes Steam attribute our window to the donor is the main deliverable of Phase 0.

3. Start Remote Play Together from the Steam friends list / overlay and invite a friend (or a second machine/account).

4. Verify on the guest side:

   • The guest sees the borderless overlay window streamed (not a black screen).
   • The guest presses buttons on their controller and the corresponding slot in the overlay lights up. This proves RPT routes guest input into our window as XInput — the foundation the whole tool relies on.

5. Press Esc in the host window to quit.

If steps 2 and 4 both work, the core premise holds and we proceed to Phase 1 (window capture + input injection). If not, we revisit the donor-attribution approach before building further.

Phase 1a: testing input forwarding locally

This needs no RPT, donor, or second account — just the host, the hook, a controller, and a target game. coop_host.exe and coop_hook.dll must sit in the same folder (the build places both in bin/<Config>/).

Requirement: run the target game windowed or borderless, not exclusive fullscreen. Exclusive fullscreen minimizes on focus loss (defeating the focus spoof) and can't be window-captured later. Only controller input is forwarded — while the game is unfocused it won't receive OS keyboard/mouse.

1. Start a DRM-free, non-anti-cheat, XInput game in windowed/borderless mode and get to a screen that reads the pad.
2. Run bin\Debug\coop_host.exe. In the Injection panel, filter for the game's .exe, select it, and click Inject & Connect.
3. Watch the Hook status section. Once it shows Attached and a non-zero "XInput polled: N/s", the game is provably reading our hook — injection works. Focus spoof: active confirms the window was found and subclassed.
4. Prove forwarding is the source: tick Forward synthetic test input. The game should now move on its own — left stick sweeping a circle, A pressed every other second — independent of your physical controller. Untick it to return control to your pad.
5. Sanity-check the focus spoof: click into another window so the game loses real focus. It should keep running/animating (not pause), and the poll rate should stay non-zero.
6. Click Stop forwarding (or quit the host) to tear down the channel.

If injection fails with an access error, run the host as administrator. If it reports "target is 32-bit", that game needs the x86 hook (a later phase).

For a quick sanity check of the forwarding core without a game, run bin\Debug\hook_selftest.exe — it should print SELFTEST PASS.

Phase 1b: video mirror (Windows Graphics Capture)

The Video mirror panel captures the injected game's window (via Windows Graphics Capture — no injection needed for video) and draws it, letterboxed, as the host window's background. This is what Steam RPT streams to guests.

1. Inject into a game as in Phase 1a (the hook reports the game's window, which the mirror uses as its source).
2. In the Video mirror panel, tick Mirror game window. The host window should now show a live copy of the game; the panel reports the capture resolution and render FPS.
3. The game can be behind the host window — WGC still captures occluded (but not minimized) windows, and focus spoofing keeps it rendering.

Requires Windows 10 1903+ for WGC; hiding the capture border needs build 20348+. This is the place to judge capture latency/stutter; if it's not good enough, the fallback is a Present-hook capture path in the same injected DLL.