Marathon Input Issues Fix：构建抵御 Overlay 冲突的 PC 游戏架构

每一位竞技类多人游戏开发者都深知这种痛苦：精心设计的 netcode 却因为 Discord overlay 而崩溃。你花了几个月时间将服务器架构优化到 30ms 以下的延迟，结果却发现玩家因为后台串流软件阻塞了游戏的 input thread 而无法击中目标。

这一幕正发生在 Bungie 即将推出的撤离类射击游戏《马拉松》(Marathon) 的 Server Slam 测试中。PC 玩家反馈存在严重的 mouse lag、指令掉帧和镜头移动迟缓。Bungie 已正式承认该问题，并指出第三方工具、直播 overlay 和特定的窗口采集方式是主要原因。

社区论坛上成千上万的玩家正在搜索 marathon input issues fix。目前的临时方案是：采集整个显示器而非特定游戏窗口，并禁用第三方 overlay。

但对于开发者来说，这提出了一个核心架构问题：为什么串流应用和 overlay 会劫持游戏输入？我们该如何设计 PC 客户端来防止这种情况？

在本篇技术深挖中，我们将分析 Windows 输入处理机制，探讨 OBS Game Capture 导致 frame pacing 问题的原因，并演示如何通过解耦输入线程来应对复杂的 PC 环境。

根本原因：Overlay 如何劫持渲染管线

当玩家使用 OBS 或 Discord overlay 时，这些应用会直接向游戏进程注入 DLL。该 DLL 会拦截图形 API 调用，特别是挂钩 (hooking) DirectX 的 Present 函数或 Vulkan 的 vkQueuePresentKHR 函数。

Swap Chain 瓶颈

通过挂钩 swap chain，overlay 会强制引擎等待其将帧缓冲拷贝到自己的内存空间。如果编码器负载过高，拷贝操作就会停顿。原本 16.6ms (60 FPS) 的帧会突然变成 24ms。由于大多数引擎在渲染 tick 之前的住线程上轮询 WM_MOUSEMOVE，渲染延迟必然导致输入轮询延迟。

构建不可阻断的输入：Raw Input API

要免疫 overlay 导致的延迟，必须放弃标准的 Windows 消息泵。依赖 WM_MOUSEMOVE 对竞技射击游戏来说是致命的。开发者应实现 Raw Input API (WM_INPUT)，并将输入轮询移至完全脱离渲染循环的高优先级独立线程。

C++ (Win32) 实现 Raw Input

void InitializeRawInput(HWND hwnd) {
    RAWINPUTDEVICE Rid[1];
    Rid[0].usUsagePage = 0x01; 
    Rid[0].usUsage = 0x02; 
    Rid[0].dwFlags = 0;   
    Rid[0].hwndTarget = hwnd;
    RegisterRawInputDevices(Rid, 1, sizeof(Rid[0]));
}

Unreal Engine 开发者：禁用平滑

在 Unreal Engine 中，务必在 PlayerController 中禁用 mouse smoothing，以避免帧率波动时输入延迟加剧。

连锁反应：客户端延迟与服务器回滚

输入延迟不仅是本地问题。在权威服务器架构中，客户端输入延迟会导致服务器收到数据包过晚，从而触发 reconciliation 逻辑，产生类似 How To Fix Player Location Desync In Uefn And Unreal Engine Multiplayer 中的 rubberbanding 现象。

通过使用 horizOn，你可以部署高度优化的游戏服务器，内置防客户端洪水攻击和同步保护功能。

PC 输入的 5 项最佳实践

1. 输入与渲染解耦：使用 1000Hz 的独立高优先级线程轮询 Raw Input。
2. 强制使用 DXGI Flip Model：使用 DXGI_SWAP_EFFECT_FLIP_DISCARD 绕过 DWM 合成。
3. 实现硬件光标：使用系统级 SetCursor 而非 UI 纹理。
4. 警告挂钩注入：检测到 OBS 等 DLL 注入且帧率下降时提示玩家。
5. 使用固定步长仿真 (Fixed Timestep)：确保物理和输入处理逻辑的一致性。

结论

开发者必须采取主动，通过实现 Raw Input 和解耦线程来确保响应性。至于后端同步？交给 horizOn 即可。