Switch模拟器Ryujinx进度报告2023-6月

Switch模拟器Ryujinx进度报告2023-6月

无论这一年过得如何，总是感觉怪怪的。几周前不是一月吗？与五月相比，虽然没有定义类型的大片让我们大放异彩，但皮克敏的粉丝们有一个演示可以沉浸其中，一个新的条目：弹丸论破开发团队的《侦探档案大师：雨码》，以及其它一些我们确信比我们更有文化的电子游戏的人都知道的游戏。上面提到的两个游戏也具有第一天的兼容性，这对于Pikmin 4皮克敏4的完整发布来说是个好兆头！

闲聊够了，我们聊聊吧。

对于那些厌倦了听到王国之泪的人，我们深表歉意。一些修复一直延续到 6 月，所以我们都可以再讨论几段。

英特尔 GPU 所有者并不特别兴奋，因为在启动这款游戏时，他们实际上是 Mac 用户背后的底层公民。英特尔 Vulkan 驱动程序有一个相当搞笑的错误，如果在返回后放置渲染屏障，它只会挂起。 如果流程可能出现分歧，则消除英特尔驱动程序上的这些障碍可以让 TotK 最终进入游戏。

我们现在必须对供应商特定的错误进行另一次检查......

最后，对于塞尔达来说，许多用户都注意到了阴郁沉积物的随机问题，其中地面纹理会进入完全破碎的状态。

用于 gloom 的压缩 3D 纹理在解压缩时进行了不正确的布局转换，并导致上面的工作量相当小。在 Vulkan 上，这个问题似乎是随机的，具体取决于是否允许它形成复制依赖项，而在 OpenGL 中，它一直被破坏，因此非常容易重现。 当 3D 深度值等于 1 时修复此布局转换可解决两个后端中的问题。OpenGL再次紧紧抓住。

有趣的是，这一更改还修复了《灵者》中长期存在的问题，即角色和NPC精灵完全缺失;与独立游戏解决AAA问题的通常趋势相反，而不是相反。

我们上个月提到，gdkchan一直在对GPU模拟器进行相当大的重构，以尽可能多地减少特定于后端的代码，其最终目标是进一步统一我们目前针对的所有后端：OpenGL，Vulkan和Metal（通过MoltenVK），以减少我们的维护承诺和技术债务。6 月份的两个更改是使用新的全局加载/存储方法实现着色器存储缓冲区、加载/存储、本地/共享和原子共享操作。

随着谣言，预告片泄漏，然后是《女神异闻录3》重制版的预告片，一些人终于注意到，当应用SMAA滤镜时，《女神异闻录4》黄金在龙神上看起来有点奇怪。该问题是将过滤应用于原始图像时发生的某些 BGRA/RGBA 交换的副产品。有人试图针对非存储映像操作更正此问题，但在这种情况下失败了。

让我们来看看一些与macOS相关的很酷的东西。上面提到的重构不仅仅是为了代码库美学，我们稍后会有很多这样的内容，而且还是为了制作烦人的东西......不那么烦人。

使用所有这些新的着色器操作，转换反馈仿真终于被上游化，并用于任何没有本机支持的设备上，而不仅仅是 Apple 芯片。此实现比用于交付macOS1的实现要干净得多，并且不到400行。一些非常值得注意的游戏现在将在我们的 Mac 主版本上运行和渲染。

一些GPU供应商不支持float64着色器操作，包括Apple和Intel。在 Switch 库中，这些工具的使用相对有限，但在少数情况下会使用它们。对于英特尔来说，添加一种机制来从 float64（双重）操作转换为支持的操作可以防止《王国之泪》中的设备丢失，而对于 Mac 来说，它最显着的修复是符文工厂 4。

macOS1 的最后一个简化的上游组件是 SPV-Cross（用于将 SPIR-V 着色器转换为 Metal MSL 的库）解决方法，以避免堆栈溢出。由于SPV-Cross似乎使用了非常深的嵌套和递归，默认堆栈大小对于某些游戏来说根本不够大，特别是Splatoon 3和Mortal Kombat 11。在 macOS1 中，通过使用自定义线程池而不是 .NET 提供的线程资源来解决此问题。这并不理想，并且是我们必须解决的更混乱的解决方法之一，以便将某些东西拿出来。

虽然 gdk 最初打开了拉取要求 t，但一位用户注意到默认堆栈大小可以在应用程序 plist 中设置为环境变量。这意味着我们不需要告诉用户手动增加堆栈大小，这意味着我们可以避免任何解决方法！原本 200 行、特定于供应商的代码部分减少到 7 行环境变量调整。

转到一些快速更改：

对可用地址空间小于 39 位的用户空间实施了地址空间变通办法。改进了内核使用 63 到 39 位的 ARM64 支持。

修复了 CPU 重新编译器中对 Windows ARM64 的支持。更接近允许Ryujinx在适用于ARM系统的Windows上启动。

为 ARM64 JIT 添加了 AES 加密指令的快速路径。减少使用这些加密指令的游戏（如《动物森友会》）中保存的大量挂起。

HID GetBusHandle服务被存根，允许新版本的NES在线和Starlink：Battle for Atlas再次启动。

自动更新程序现在将忽略用户引入目录的文件。 允许在更新后保留在可执行文件文件夹中放置钩子的重新着色和其他工具。

虽然所有这些肯定很多，但六月的大部分时间都被一件事垄断了......点网...格式。

为了提供一些背景知识，Ryujinx当然是开源的，因此我们在项目的几个领域从许多不同的人那里获得了外部贡献。虽然从表面上看，这听起来很棒，但事实并非如此简单。每当外部人员做出贡献时，我们的核心开发人员可以继续从事他们正在做的事情，或者花费数小时审查这些外部更改，以确保他们按照他们所说的去做，不破坏任何东西，并符合我们对代码库的期望标准。目前没有人全职从事Ryujinx工作，要求他们将业余时间投入到归结为批改家庭作业的工作中，并不总是最吸引人的前景。

不过这是 2023 年。当然，我们可以将一些更琐碎的东西自动化到机器人或其他东西中，让审阅者真正专注于功能，而不必留下数百条评论，例如“删除额外的间距”和“为什么在这里添加额外的行”。答案是肯定的，但我们需要先做几件事。

.NET 有一个漂亮的内置工具，称为 Format，正如您所期望的那样，它格式化代码以符合标准 C# 代码样式。第一次运行时，它产生了一个相当巨大的差异，超过30，000行代码需要更新，改变了模拟器的许多部分，基本上不可能作为一个同质块进行审查。决定为每个项目格式化代码库，这个 30K 怪物被分成大约 50 个不同的拉取请求。我们的更新日志的追随者可能已经厌倦了重复的行“代码清理。游戏中没有预期的变化“，但这是解释。

所有这些的最终目标是添加一个机器人工作流，该工作流可自动审查代码样式，并最终使所有相关人员的审查过程更加轻松。虽然这对于进度报告来说并不是特别华丽，但它占据了本月的大部分时间，我们认为讨论这一点很重要。这是每个一定规模的开源项目都必须考虑的事情;如何使外部贡献与核心开发技巧的时间平衡对每个人都有利。

在相当沉重的词结束之后，我们不会继续喋喋不休很长时间。

作为标准，我们要感谢所有在 Patreon 上支持我们、通过 GitHub 测试和贡献代码的人，甚至是那些放弃自己时间在我们的 Discord 上与他人进行故障排除的人。我们希望在上面迭代它，但时间确实是我们最宝贵的资源，你们所有人都以各种方式给了我们更多的时间，为此我们永远感激不尽！

我们下个月见。