Switch模拟器YUZU进度报告2022-4月（Project GAIA）

Switch模拟器YUZU进度报告2022-4月

大家好，四月真是太棒了！我们将讨论 CPU 和内核性能改进、几项 GPU 模拟更改、UI 调整等等！

继续拯救桃花公主

继续它的工作以更好地支持官方 GameCube/Wii 和 Nintendo 64 模拟器（代号 Hagi和 Hovercraft）， byte引入了几个新的 PR，以进一步提高其中包含的标题的兼容性 超级马里奥3D全明星.

byte首先实现了对 GLSL 的支持 超级马里奥阳光，因为不是每个人都可以运行 Vulkan模式。这是通过添加对间接寻址在 OpenGL 中。

此更改目前不包括对 GLASM 的支持，因为我们的开发人员不太喜欢处理 NVIDIA 程序集着色器代码。

然而，这只是成功的一半。适当的 OpenGL 支持 超级马里奥阳光 和 超级马里奥银河 需要解决我们对老化 API 的旧限制：损坏的 Z 比例反转。

大多数 Switch 游戏使用 OpenGL（流行的免费图形 API）或 NVN（控制台独有的专有 NVIDIA API）。可以说，NVN 在操作方式上比 Vulkan 更接近 OpenGL。

Switch 上的 Tegra X1 GPU 足够灵活，可以让游戏开发者自行决定更改坐标系。虽然大多数游戏的行为会更接近 OpenGL 的预期，Z 轴背对相机， Hagi和 Hovercraft模拟游戏（使用 Vulkan 渲染，并且仅适用于 Switch 上的少数游戏）具有倒置的坐标，并且 Z 轴面向相机，这是 Vulkan 游戏期望的原生渲染方式。

byte的Z轴图

如果您想玩，这不是问题 超级马里奥银河 或者 超级马里奥阳光 在带有 yuzu 的 Vulkan 后端的 yuzu 中，因为行为与游戏的预期相匹配。但是，如果您尝试使用 OpenGL 进行游戏，yuzu 将无法正确解释由于 Z 比例反转导致面翻转，因此仅渲染对象的背面。

解决方法很简单，翻转正面当 Z 轴反转时。

超级马里奥暗影

超级马里奥阳光

接下来，您可能已经注意到 超级马里奥阳光 在底部用黑条渲染。这是因为 Wii 和 GC 游戏本身使用的宽高比与我们习惯的通常 16:9 不同。相反，游戏以 5:3 的纵横比呈现。 超级马里奥银河 通知系统将屏幕显式裁剪为其原始分辨率 1920x1012，但 超级马里奥阳光 没有，所以yuzu之前没有尝试裁剪游戏，导致渲染底部出现明显的黑条。

裁剪过程示意图

虽然游戏比例在 超级马里奥阳光 中可以说黑条看起来更正确，但这不是任天堂想要的游戏的方式。为了准确起见，byte解释了游戏的隐式裁剪请求，这会拉伸图像以匹配 Switch 的原生 1920x1080 分辨率，两者都适用于 Vulkan OpenGL 模式 .

超级马里奥阳光裁剪前

超级马里奥阳光裁剪后

在之前的报告中，我们提到了 S8D24 < > ABGR8 纹理转换如何允许 超级马里奥银河 星位以正确运行。现在轮到OpenGL 加入了。

S8D24到ABGR8纹理转换图

我们上个月提到了 超级马里奥64 如何开始在yuzu上运行有特殊要求。大多数游戏都会编译他们的代码 ahead-of-time( AOT )，即在运行之前。操作系统的工作是执行预编译的二进制代码，然后你就可以玩游戏了。

超级马里奥64，另一方面，运行 just-in-time(JIT)，以便更容易地开发 Hovercraft模拟器，并允许重复使用相同的 Hovercraft不同游戏的二进制文件。这 Hovercraft模拟器加载 超级马里奥 64 的本机 Nintendo 64 ROM，然后其 JIT 编译器获取 ROM 并将原始 MIPS Nintendo 64 的 AArch64 （Switch 的 CPU 架构）指令。只有这样，操作系统才会执行游戏代码。

Ahead-of-time 与 Just-in-time 编译图

这类似于 Dynarmic 。

在独立游戏上使用 JIT 编译所需的 JIT 服务是 yuzu 没有实现的功能，仅仅是因为没有其他游戏需要它。此外，直接实现它也存在一些障碍，因为它需要调用游戏提供的自定义代码，而以前的任何服务实现都不需要这些代码。所以，除了一些刚开始保存的代码 , byte实现了 HLE JIT 服务允许 Hovercraft模拟器运行和 超级马里奥64启动。

在单独的 PR , byte添加了 JIT 服务接口如何操作的文档。如果需要，这应该有助于其他开源项目。

当然，这还不够 超级马里奥64可以玩，因为还有渲染问题需要解决。

它从来没有那么简单……但让我们试着简单地解释一下。 Nintendo Switch 游戏将自己的独立 GPU 驱动程序与每个游戏捆绑在一起。这样做是为了提高兼容性，如果驱动程序版本有问题，您无需更新世界上的任何一个固件，因为更细了也没有用，它是驱动程序的问题。

由于未知原因，无论是 Hovercraft模拟器或捆绑的 GPU 驱动程序报告顶点缓冲区太大，特别是与游戏实际使用的缓冲区相比。无论是包含的模拟器中的问题还是驱动程序错误，我们都无法确定，但我们确实需要解决这个问题。

错误的顶点缓冲区大小图

因此，byte并没有使用疯狂报告的缓冲区大小，而是说不！并使用后备内存大小反而更好。

超级马里奥 64

Vulkan 的性能目前并不出色，但您终于可以享受所有 超级马里奥全明星 中的三个游戏，使用这两种 API 的游戏。

最后， Morph 实施了一个修复程序以保持 Web 小程序在前台打开，作为 超级马里奥全明星 游戏需要它，否则它们会在游戏过程中崩溃。

一般图形修复

继上个月的 NVFlinger 重写之后， bunnei 继续跟踪问题和错误报告。他修复了报告的问题并进一步清理了代码以提高代码质量。在此处查看 NVFlinger 重写的代码更改。

异度神剑2 和 塞尔达无双：灾厄启示录 会遇到一些有趣的问题，这些问题是由新的 GPU Garbage Collector作为一部分引入 Project Y.F.C.. 在一月份的报告中谈到了这些变化。

正如您在下面的第一图中看到的那样，异度神剑2会在 OpenGL 中使用大量的 VRAM（顶栏）。第二图显示了修复实施后的结果。

异度神剑2 VRAM测试图

Age of Calamity显示有趣以随机间隔

Blinkhawk 修复了问题这两款游戏都可以重新开始更好的运行。

通常在模拟中，当您解决一个问题时，会弹出另一个问题。实现的裁剪修复问题中 超级马里奥全明星 在 Vulkan 中破坏自制应用程序的渲染具有一些意外的副作用。值得庆幸的是，Morph 在代码中添加了魔法线解决了这个问题。

天际线框架：第 3 部分

在让 Skyline 修改框架正常工作方面取得了重要进展。

tech-ticks 一直忙于收尾工作 . 最新的变化包括：

更好的 LayeredExeFs支持，这导致更容易的 mod 分发和自我更新功能。

支持 SO_KEEPALIVEsocket 选项，它允许 Skyline TCP 记录器运行。

实现 DNS 地址解析，这是使用 HTTPS 请求的插件所必需的。

不得不提的是，虽然 Skyline 内核支持基本完成，但 yuzu 代码库中的错误阻止了 modding 框架的正常运行。例如，由于潜在的模拟问题， ARCropolis 直到 Project Gaia已经完成，前面提到的一些更改需要我们进行一些微调才能正常运行。

还有更多工作要做，但离我们更近了。我们快可以看到最终的结果了！

用户界面改进

Merry 的核心开发者 Dynarmic，对附加组件游戏属性窗口进行了一些更改，提高列宽。

低分辨率用户会喜欢这个改动

热键配置窗口也得到了一些更改，更改最小列宽。

它也非常适合 GNOME 用户

这两项更改对于臃肿或大小未优化的桌面环境（如 GNOME Shell）都非常有益。

Tachi107 修复了我们日志记录中的一些令人尴尬的拼写错误，并更新了关于柚子窗口恰当地提及我们的新执照， GPLv3.0 . 这个号是因为我们想为更新的修订敞开大门。

YUZU关于框的截图

不止于此，Taichi 进行了一些清理并对 Flatpak 构建进行了改进，包括使用正确的应用程序ID，修正一些拼写错误，以及添加启动参数以使yuzu在Linux上默认使用独立显卡而不是集成显卡。

Docteh 在改进 yuzu 的界面方面也有很大帮助。

通过一些手动设置，他们设法绕过了一些 Qt 限制，以显示更具可读性的超链接于我们的黑色主题中。

超级链接变的更容易看到

感谢我们 Discord 服务器，Docteh 发现 Qt API 中的一些怪癖导致列出的游戏的兼容性状态无法翻译。原因在于 QObject，具体细节可以在修复游戏兼容性列表翻译中的得到 . 现在状态是以相应的语言正确现实了。

翻译更加准确

同样，手柄方面也没有正确显示。同样的问题，这次也得到了修正。

按键设置更加准确

内核和 CPU 仿真更改

让我们从三月份发生的两个变化开始。

我们的常驻bunnei继续他的工作，重写yuzu的内核内存管理以使其准确到最新的系统更新。这一次，他解决并修改了内核代码内存的映射和取消映射方式 .

在 Switch 的上下文中，代码内存支持允许游戏和应用程序动态加载和卸载其代码的较小部分。由于这些变化，任天堂明星大乱斗在加载/卸载 NRO 时不再导致内存访问问题，从而使游戏在长时间游戏中保持稳定。

bunnei 还为（Switch）内核对象迁移了平板堆从主机堆内存到模拟来宾内存。通过这一更改，yuzu 的内存布局现在与控制台更加匹配。

一个slab代表一块连续的内存。堆是用于任何内存的通用术语动态随机分配。

平板堆是用于存储客户内核对象的空间。通过将这些从主机 (PC) 堆内存 (RAM) 移到模拟 (Switch) 内存，我们可以确保内核对象永远不会超出系统限制并导致主机（PC）上的内存泄漏。

线程本地存储 (TLS)，给多线程进程中的每个线程分配存储的机制线程特定的数据，也被重写，使其准确到最新的 HorizonOS 行为。

通过这些更改，我们现在已经完全修复了影响一些游戏的内核内存对象泄漏，但由于之前的实现允许无限分配，因此在很大程度上我们没有感觉到而已。

回到 4 月改动列表，bunnei 也重新实现了 yuzu 处理线程分配用于 HLE 服务接口。

服务是在后台运行的等待传入请求的系统进程。 Switch 的HorizonOS 具有执行各种任务的各种服务，例如音频、蓝牙等。

以前，我们曾经为每个 HLE 服务接口分配一个主机线程，因为一些服务线程可能需要等待很长时间才能完成，例如网络或文件系统访问，以及我们不支持从主机线程重新调度模拟线程。

被阻塞的线程必须等到阻塞它的操作完成，例如 I/O 或只是休眠一段时间。

这种方法的问题在于，由于它是调度服务线程的主机（Windows 或 Linux），yuzu 可能会产生奇怪的行为，特别是在具有硬件限制的系统上，因为每个服务产生一个线程以及我们模拟的服务实现的绝对数量.

通过重写，yuzu 现在有一个“默认服务线程”，用于 99% 的非阻塞服务方法。对于时间敏感的服务和需要阻塞的服务，我们仍然允许创建线程（例如 Audio、BSD、FileSystem、nvdrv）

这将服务线程数从两位数减少到个位数，从而提高了稳定性和一致性，尤其是在内核较少的系统上。拥有 4 线程 CPU（2 核 HT/SMT，或 4 核）的用户应该会在大多数游戏中看到性能和稳定性的提升。

为正确关闭行为而进行的另一场战斗已经打响并取得了胜利。 yuzu 目前不模拟 HorizonOS 内核的多进程能力，因为它不需要模拟任何游戏。但是，游戏使用的多进程 API 仍然需要按照他们期望的方式进行管理。所有 HorizonOS 服务都有一个端口（用于客户端和服务器），用作游戏进程和服务进程之间的通信通道。为它们的每个通信接口打开一个会话，它们由各自的内核对象管理。当游戏关闭客户端端口时，服务关闭服务器端口，一切都关闭。

我们之前实现的问题是 yuzu 没有正确跟踪所有 KServerPort和 KServerSession每个服务的对象。正因为如此，服务没有正确关闭，这反过来又导致了进一步的问题。

这最初工作得很好，但是当我们将客户内核对象迁移到模拟客户内存时，正如我们之前提到的那样，它倒退了。 bunnei 发现了问题并迅速重新修正了我们如何跟踪这些内核对象 .

通过在一个地方注册/注销开放端口和会话，我们现在可以更好地跟踪这些内核对象。并且通过确保在我们关闭所有服务和内核时关闭它们，我们可以获得更好的模拟关闭行为。

输入更改和一般错误修正

如果用户在使用鼠标平移时为其鼠标设置了非常高的 DPI 值，则光标可能能够逃离渲染窗口。 IamSanjid 实施了所需的修复，包括更好的准心时间来解决这个问题，谢谢！

German77 为我们准备了几个修复程序。

让我们从一个有趣的开始， yuzu 的屏幕截图功能可以轻松地以缩放器当前设置的分辨率保存瞬间。截屏热键可能会被发送垃圾邮件，如果发送了多个截屏请求，会导致 yuzu 崩溃。如果将渲染分辨率设置为较高的值，这可能会变得更糟。为了解决这个问题，yuzu 现在在处理捕获时忽略新请求，并在日志中保存警告。

模拟总是有改进的空间，因为没有什么是真正完美的。这一次，german77 专注于在我们的输入模拟中发现的不准确之处。

IsSixAxisSensorFusionEnabled已实施通过对所有 Sixaxis 功能进行逆向工程，并通过与在 Switch 上完成的单元测试自制程序结果进行比较来验证。这应该潜在地提高运行准确性。

HID 除其它外，负责处理输入命令这会导致输入过程中的不匹配或延迟，并可能使游戏读取完全不正确的数据。

显然这并不理想，因此 German77 摆脱了内存重复并使用永远神奇的 * 指针直接访问共享内存。这可以修复影响无数游戏的错误，最大的例子是 精灵宝可梦Let's GO！皮卡丘/伊布 难以检测控制器的游戏。

现在将通过使用队列触发 . 这样做的好处是不必等待 UI 响应，从而减少它们的延迟。

模拟摇杆得到了一些改进，在它们的映射中有几个重要的变化：

默认最大范围现在设置为 95%，以确保游戏可以使用整个范围。例如，此更改可避免角色在游戏中以特定角度行走时，例如 宝可梦传说：阿尔宙斯. 最小范围从 50% 降低到 25%，提供了更高的精度，特别是对于那些使用摇杆来玩赛车游戏的人。自动中心校正现在更强大，无需依赖更强大的死区值即可避免漂移。如果手动映射按钮，现在可以手动删除单个轴值。

以前，只有玩家 1 可以通过按下按钮自动重新连接控制器。其他玩家只有在使用键盘时才能这样做。 German77 的 pull requests 旨在解决这个问题，允许其余 7 名玩家中的任何一个重新连接他们的控制器 . 执行游戏模拟的人不再享有特权。

在撰写本文时，此更改正在测试中，因为它可能会导致错误。请务必使用暂停游戏再恢复游戏来测试！

未来项目

Project Y.F.C.距离发布计划中的第一部分不远了。

Project Gaia继续缓慢但肯定地进展着，现在导致一些以前损坏的游戏终于可以启动了。 我的世界 和 真人快打11