XeUnlock

[size=5][b]XeUnlock[/b][/size]

《生化危机：安魂曲》内置了[ b]全部三款英特尔 SDK**——XeSS 超分辨率、XeSS 帧生成和 Xe 低延迟——并已完全接入渲染管线，与 DLSS 和 FSR3 并肩作为引擎的一等类。

卡普空交付了渲染集成，却从未交付配置层。选项中没有任何条目暴露这些功能。

XeUnlock 是一个独立的 REFramework Lua 脚本，它调用引擎自身的接口并将它们开启。

[list] [][b]XeSS 超分辨率* — 可在运行时选择质量（游戏硬编码为最激进的模式）[/] [][b]XeSS 帧生成** — 启用，使用游戏的 [b]原生 XeFG，而非任何转译层[/] [][b]Xe 低延迟** — 开箱即用，无需操作[/] [][b]其他超分辨率技术** — 同样可选择 FSR1 / FSR2 / FSR3 / NIS / AASR / GSR2[/] [/list] [b]不修改任何游戏文件。* XeUnlock 是一个脚本外加两个现有的免费工具。没有任何内容被修补，没有任何内容被重新分发，游戏更新也不可能破坏一个不存在的二进制补丁。

[line]

[size=4][b]阅读前说明：这是如何制作的[/b][/size]

[b]这是借助 LLM 构建的** — Claude Opus 5，驱动 Claude Code，历时两次会话完成。

我是一名医学生，也是一名玩家，并不是程序员。我想为自己的 Arc 显卡正确启用 XeSS，于是使用 Claude Code 实现了这一目标。最终效果不错，与其私藏，不如分享——Arc 的模组社区还很薄弱，而事实证明这扇门一直是开着的。

[b]我并非声称这是最佳或唯一的解决方案。** 真正以写代码为职业的人很可能会改进它，或找到一条更简洁的路径。请将以下发现视为一个可验证的起点，而非权威结论。

我能保证的是：所有标记为 [b]MEASURED**（实测）的内容均在游戏内实际测量过，数据来自日志而非印象。所有未达到此标准的内容均明确标记为 [b]UNTESTED**（未测试）或 [b]NOT DIAGNOSED**（未诊断）。如果早期结论被证明是错误的——确实有几个——修正之处会保留在文本中，而不是悄悄删除。

如果你懂得更多，请善加利用。

[line]

[size=4][b]为什么不用 OptiScaler？[/b][/size]

OptiScaler 非常出色，但它解决的是另一个问题。它做的是[ i]转译** — 拦截 DLSS 或 FSR 调用并将其重定向到 XeSS/XeFG。

《生化危机：安魂曲》不需要转译。libxess.dll、libxess_fg.dll 和 libxell.dll 已经与可执行文件一起静静地躺在旁边，被静态导入，完整生命周期已实现。缺少的仅仅是 UI 中那个开关。

XeUnlock 翻转了这个开关。少了一个中间层，并且运行的帧生成是由卡普空自己的引擎驱动的。

[line]

[size=4][b]系统要求[/b][/size]

[b]仅在单一机器上测试过。** 其他 Arc 显卡、驱动、分辨率和游戏版本均未测试。欢迎反馈报告。

[code] GPU Intel Arc B580, driver 32.0.101.8991 Output 2560 x 1440 Game Resident Evil Requiem (Steam), re9.exe[/code] [b]你需要下载的工具**

[code] REFramework nightly 01398 -> /dinput8.dll github.com/praydog/REFramework-nightly

Special K release SK_26_8_12 -> /reframework/plugins/dxgi.dll github.com/SpecialKO/SpecialK[/code] [b]Special K 是必需的。** 没有它，启用帧生成会导致 REFramework 每 11 秒重新挂钩 D3D12，造成严重卡顿。详情见下文。

[b]游戏文件夹中已有的文件** — 你无需下载或替换这些文件：

[code] libxess.dll 2.0.2.53 libxess_fg.dll 1.2.0.87 libxell.dll 1.2.0.9[/code] [line]

[size=4][b]安装方法[/b][/size]

[b]1.[/b] 安装 REFramework — 将 dinput8.dll 放置在 re9.exe 旁边。

[b]2.[/b] 安装 Special K [b]作为 REFramework 插件**。从发布压缩包中解压 SpecialK64.dll，将其重命名为 [b]dxgi.dll**，并放入：

[code]/reframework/plugins/dxgi.dll[/code] [b][color=#c0392b]切勿将其放入游戏根目录。[/color][/b] Special K 正常的“本地安装”（DLL 与 re9.exe 同目录）会导致游戏根本无法启动（错误 0xC0000142）。插件文件夹是唯一可行的拓扑结构。

[b]3.[/b] 将 xeunlock.lua 放置在：

[code]/reframework/autorun/xeunlock.lua[/code] [b]4.[/b] 在游戏的图形菜单中，关闭 [b]Motion Blur**（运动模糊）和 [b]Lens Distortion**（镜头畸变）。这是必需的——原因见下文。

[b]5.[/b] 启动游戏，按 [b]Insert** 打开 REFramework 覆盖层，然后展开 [b]XeUnlock**。

最终布局：

[code] / re9.exe dinput8.dll REFramework reframework/ plugins/dxgi.dll Special K autorun/xeunlock.lua XeUnlock[/code] [line]

[size=4][b]必需的游戏设置[/b][/size]

[code] Motion Blur -> Off Lens Distortion -> Off (同时控制色差)[/code] 开启这些选项时，在较高画质档位下会出现严重的残影。关闭它们则完全消失——在所有画质档位下，无论是否开启帧生成。[b]MEASURED（实测）

[b]这不是 XeSS 的缺陷。** 时间性超分辨率技术通过运动矢量重建图像。运动模糊会涂抹输入帧，破坏像素与矢量的对应关系。镜头畸变和色差会在这些矢量计算[ i]之后**扭曲屏幕空间中的图像，因此超分辨率器接收到的一帧与它所被告知的运动不再匹配。累积的时间信息越多——即画质档位越高——问题就越严重。

[line]

[size=4][b]使用方法[/b][/size]

[b]第一步 — 选择超分辨率技术。** “Verify which are available”（验证哪些可用）会查询引擎。在 Arc B580 上：

[code] available FSR1, FSR2, FSR3, XESS, NIS, AASR, GSR2 not available None, DLSS, DLAA, MetalFX (both), PSSR, NDSR, DirectSR[/code] 你的选择[ b]会保留** — 游戏会在退出时将其写回 config.ini。

[b]第二步 — 画质档位。** “Probe level names”（探测档位名称）会从引擎填充面板。对于 XeSS：

[code] 0 NativeAA <- 最佳画质 1 UltraQualityPlus 2 UltraQuality 3 Quality 4 Balanced 5 Performance 6 UltraPerformance <- 最激进[/code] 有两点需要了解：

[list] [][b]索引空间因超分辨率技术而异。* XeSS 的索引 0 不是 FSR3 的索引 0。这就是为什么面板询问引擎而不是硬编码一个表格。[/] [][b]画质档位不会持久保存。** config.ini 中没有 XeSS 画质键——这个缺失就是最初的缺陷。每次游戏会话都需要重新选择。[/] [/list] [b]第三步 — 帧生成。* “ENABLE XeSS FG”（启用 XeSS FG）将开启原生 XeFG。

[line]

[size=4][b]实测结果[/b][/size]

Arc B580, 2560x1440, 固定场景，站立不动：

[code] base, no frame generation ~75 fps

• XeSS Frame Generation ~125 fps
• Arc Control 4x MFG override ~204 fps[/code] 多帧生成通过[ b]Arc Control 的覆盖功能**工作，叠加在原生 XeFG 之上。原生 XeFG 运行是前提条件，而 XeUnlock 提供了它。

[b]已确认可用的组合：** [list] []XeSS 超分辨率 + FSR3 帧生成[/] []FSR 3.1.5 超分辨率 + XeSS 帧生成[/] [/list] 这两层确实相互独立——你可以任意方向混合不同供应商的技术。

[line]

[size=4][b]已知问题[/b][/size]

[b]原生 MFG 无法工作。** [b]REPRODUCED 3x**（复现 3 次） set_GenerateFramesCount 返回成功，但每次读回都是 0。这不是实际障碍——多帧生成通过 Arc Control 的覆盖功能正常工作。面板中故意保留了这些按钮，因为同一个门面暴露了一个 DLSS 接口，可能在 NVIDIA 硬件上表现不同。

[b]游戏运行时插入或拔出控制器会导致崩溃。** [b]NOT DIAGNOSED**（未诊断） 在[ i]游戏运行期间连接或断开控制器会导致崩溃。更准确地说：这[ b]不是同时使用控制器和键盘，也[ b]不是**切换输入模式——而是游戏打开后，连接/断开事件本身导致崩溃。解决方法：在启动游戏之前连接控制器。

目前还没有证据——发生此问题的会话正常退出，没有生成崩溃日志。关键是，[b]尚不清楚未修改的游戏是否能承受热插拔**。首要怀疑对象是 Special K，它挂钩 XInput 并管理控制器槽位，但这只是猜测。

[b]Special K 会设置自己的帧率上限。** [b]MEASURED**（实测） Special K 根据你的刷新率将 TargetFPS 写入 dxgi.ini。在 144 Hz 显示器上，它写入了 137.55，之后帧率便卡在 ~138 [i]无论内部分辨率如何，XeSS 和 FSR 都是如此**。这看起来完全像超分辨率器的帧率上限，但实际上不是。将 TargetFPS=0.000000 以移除该限制。请注意 dxgi.ini 是 UTF-16 编码——请使用支持 Unicode 的编辑器进行编辑。

[line]

[spoiler]

大部分内容可推广到其他 RE 引擎游戏。

[size=4][b]via.render.* 接口是静态门面[/b][/size] [b]MEASURED（实测）

这是最重要的发现，搞错它要耗费数天时间。via.render.FrameGenerationInterface 和 via.render.UpscalingInterface [b]没有实例**。每个方法都是静态的：

[code] setFrameGenerationAlgorithm Static HasThis=no isFrameGenerationAvailable Static HasThis=no getFrameGenerationAlgorithm Static HasThis=no get_XeSSInterface Static HasThis=no setUpscalingAlgorithm Static HasThis=no set_UpscalingQuality Static HasThis=no[/code] 调用它们时令 this = nil：

[code] local FGI = sdk.find_type_definition("via.render.FrameGenerationInterface") FGI:get_method("setFrameGenerationAlgorithm"):call(nil, 3) -- 3 = XeSS[/code] 相比之下，via.render.XeSSFrameGenerationInterface 确实[ i]是基于实例的，你需要从[ i]静态 getter get_XeSSInterface() 获取该实例。

[b]搞错此处的症状：*sdk.hook 安装在所有方法上但从未触发——在 11,041 帧中通过空计数器测量得出。整个类型数据库中没有返回或持有 FrameGenerationInterface 的内容；app. 层从未触碰它。如果你在寻找实例，你就是在寻找不存在的东西。先检查 SDK 转储中的 flags 字段——只需 45 秒。

[size=4][b]大多数状态 getter 会撒谎[/b][/size] [b]MEASURED（实测）

[code] isUpscalingAvailable(alg) real value isFrameGenerationAvailable(alg) real value get_EnableUpscaling() real value getUpscalingQualityDisplayName(i) real value *

getUpscalingAlgorithm() ALWAYS 0 get_UpscalingQuality() ALWAYS 0 get_UpscalingQualityCount() ALWAYS 0 getFrameGenerationAlgorithm() ALWAYS 0 get_UsingFrameGenerationAlgorithm() ALWAYS 0 getUpscalingQualityDisplayValue(i) ALWAYS 0[/code] getUpscalingAlgorithm() 返回 0/None，而 XeSS 明确以 1506x848 运行。[b]不要使用这些函数来验证任何内容。 通过图像和帧率确认。另一方面，setter 确实有效。

• getUpscalingQualityDisplayName 仅在[ i]set_EnableUpscaling(true) 之后**返回真实名称。在此之前返回 nil、类似 "erConfig" 的垃圾字符串和乱码。超出有效范围的索引会读取相邻内存——向上探测并在第一个没有名称的索引处停止。

[size=4][b]11 秒卡顿及其为何 Special K 能修复它**[/b][b]MEASURED**（实测）

启用 XeFG 且进程中只有 REFramework 时，游戏会以固定周期严重卡顿。setFrameGenerationAlgorithm(3) 执行后 123 毫秒，D3D12 被取消挂钩。此后，REFramework 重复 “Sending rehook request -> Unhooking D3D12 -> Hooking D3D12”：

[code] delta = 11.007 s delta = 11.010 s delta = 11.008 s ... 十六个间隔，全部在 11.006 至 11.010 秒之间[/code] 同样的三分钟测试，有无 Special K 插件：

[code] REF only + Special K Sending rehook request for D3D 17 0 Restored descriptor 148 1[/code] 仅剩的一次描述符恢复发生在 XeFG 启用之前。剩余的五个取消挂钩事件均跟随由用户发起的算法更改 50-150 毫秒——没有一个是自发发生的。

REFramework 在启动时警告其底层机制：

[code] [IntegrityCheckBypass]: Attempting to hook JobQueue::SubmitDescriptor as a fallback for RE9. This may cause lag during integrity check jobs[/code] 链条如下：XeFG 重建 D3D12 交换链，REFramework 丢失其渲染挂钩并重新建立，游戏的反篡改机制检测到经过修改的作业描述符，REFramework 批量恢复它们，产生延迟，然后重复。[b]卡顿并非 XeFG 的错 — 而是 REFramework 在 XeFG 重建交换链时驻留在进程中。Special K 自己包裹了交换链，因此 REFramework 的挂钩能在重建后存活。这也解释了随之消失的两个副作用：覆盖层消失，以及 re.on_frame 静默失效。

[size=4][b]Special K 以不受支持的方式加载[/b][/size] [b]MEASURED（实测）

测试了三种拓扑结构，两种会导致游戏崩溃：

[code] /dxgi.dll + REFramework 0xC0000142 at launch, nothing created at all /dxgi.dll alone loads, then crashes ~10 s later during XeSS context creation reframework/plugins/dxgi.dll WORKS[/code] 作为插件，Special K 由 REFramework 在进程启动[ i]后**通过 LoadLibrary 加载，而不是在 Windows DLL 初始化期间竞争。0xC0000142 是 STATUS_DLL_INIT_FAILED——正是那个加载时冲突。

[b]请注意这是一个巧合的好运，而非设计好的集成。** REFramework 的插件加载器只是调用 LoadLibrary；Special K 并未实现其任何插件 API。这就是为什么应该固定 REFramework 版本的原因。

[size=4][b]游戏在任何模组之前已经代理了 DXGI[/b][/size] [b]MEASURED（实测）

sl.interposer.dll（NVIDIA Streamline）随游戏一起发布，并默认包裹 DXGI。你添加的任何包裹层都是该接口上的第三层。在尝试 ReShade、OptiScaler 或类似工具之前，值得了解这一点。

[size=4][b]数据层中的根本原因**[/b][b]MEASURED**（实测）

为什么选项菜单完全没有任何 XeSS 条目：

[code] app.GameOptionRuntimeSourceHandler_FrameGeneration _SupportDLSS = true offset_from_base 0x28 _SupportFSR3 = true offset_from_base 0x29 _SupportXeSS = false offset_from_base 0x2a <-- here[/code] 来自 natives/STM/AppSystem/GameOption/GameOptionCatalog.user.3 的序列化 RSZ 字段。链条：_SupportXeSS = false，reloadSourceItems() 构建 [Off, FSR3 2x]，config.ini 请求 “XeSS 2x”，indexOf 返回 -1，回退到 Off。

注意 _SupportDLSS 在没有 NVIDIA GPU 的机器上是 [b]true**。这些不是能力检查。它们是数据，而卡普空出厂时关闭了 XeFG。

在松散文件中翻转该布尔值将使游戏通过其自身的选项系统启用 XeFG，而无需任何脚本——但 PAK 条目表已加密（KPKA v4.2），绕过它使用静态接口被证明更简单且足够。

[size=4][b]XeSS 正在使用较旧的 AI 库[/b][/size] [b]UNTESTED（未测试）

[code] ExternalAIL: 4, Built-in AIL: 3 Using built-in context[/code] 英特尔驱动附带 XeSS AI 库版本 4；游戏使用版本 3（内嵌于 libxess.dll）。在 Arc 显卡上，你可能会期望使用驱动的。作为潜在画质提升点，留待有心人探究。[/spoiler]

[spoiler]

以下每项都至少耗费了一次游戏启动。

[b]通过替换方式使用代理 DLL 会导致游戏崩溃。** [b]5 VARIANTS TESTED**（测试 5 种变体） 用代理替换任何现有游戏 DLL 并将原始 DLL 重命名后转发，每次都会在启动时崩溃——包括一个带有 72 个转发器的空代理、一个空的 DllMain、无 CRT、大小 8 KB。每次签名相同：一个未处理的异常，恰好有两个堆栈帧，无转储。游戏的反篡改机制在 REFramework 的日志中指明了自身机制：线程调度器破坏器、PE 头完整性检查、堆栈破坏器。

[b]关键区别在于替换与新增。** 原地修改文件有效——对 libxess.dll 进行 4 字节编辑运行良好。添加一个遮蔽系统 DLL 的 DLL 有效——REFramework 就是这样加载的。替换游戏 DLL 则不行。

[b]Special K 的本地安装。** 上文已述。

[b]寻找 via.render.* 接口的实例。** 上文已述。

[b]使用 re.on_frame 测量帧生成。** 它计算引擎帧数，对生成的帧视而不见——我们的内部计数器读数为平坦的 ~75，而外部覆盖层显示 125。使用外部计数器。[/spoiler]

[line]

[size=4][b]注意事项[/b][/size]

[list] [][b]单机测试。* Arc B580、驱动 32.0.101.8991、1440p、单一游戏版本。此处任何内容均未在其他环境复现。[/] [][b]固定你的 REFramework 版本。** Special K 插件的配置并非受支持的集成，可能静默失效。[/] [][b]Getter 会撒谎。** 如果你扩展脚本，请通过图像和帧率验证，切勿通过读取状态返回。[/] [][b]画质索引表从引擎读取，而非硬编码。** 如果游戏更新更改了它，面板会跟随。不要硬编码——脚本的早期版本确实如此做，并且顺序完全反了。[/*] [/list] [line] [size=4][b]Github: [url=https://github.com/GabrielPatchZero/XeUnlock]GabrielPatchZero/XeUnlock: Enables the native Intel XeSS, XeSS Frame Generation and XeLL that ship unused inside Resident Evil Requiem. REFramework script, no game files modified.[/url][/b][/size] [line]

[size=4][b]致谢[/b][/size]

[list] [][b]REFramework* 作者 praydog[/] [][b]Special K** 作者 Kaldaien / SpecialKO[/] [][b]OptiScaler** — 感谢其 RE Requiem wiki 页面将 Special K 指向为卡顿修复方案，以及指向插件文件夹的说明，该说明最终被证明是有效的拓扑结构[/*] [/list] XeUnlock 不修改任何游戏文件，也不重新分发任何内容。