Switch模拟器Ryujinx进步报告2022-1月
宝可梦传说：阿尔宙斯
新的一年，新的一个月，新的进步！ 我们希望每个人都像我们一样享受新的一年。 2022 年已经有了一个全新的主要系列精灵宝可梦，精灵宝可梦传说：阿尔宙斯 已经是一场冒险。 除了这个大版本，我们一直在努力处理我们本月能够完成的大量 GPU 更新和错误修复。
Patreon目标：
Amiibo Emulation - 于 2021 年 3 月合并到主版本中。
虽然兼容性接近完美，但 Amiibo 仍有一些改进可以在相关的 Github 问题上进行跟踪
自定义用户配置文件 - 于 2021 年 4 月合并到主版本中。
Vulkan GPU 后端 - 仍在进行中 ，已交付公共测试版本。
ARB 着色器 - 目标于 2021 年 4 月实现。 正在与 Vulkan 一起进行工作，请稍等片刻，直到我们能够将此更新交付到我们满意的状态。
通过使用 OpenGL API 提高 NVIDIA GPU 上的着色器编译速度，ARB 着色器将进一步减少首次运行时的卡顿。
2000 美元/月 - 纹理包/替换功能 - 徘徊在这个水平！
这将有助于替换游戏中的图形纹理，从而实现自定义纹理增强、备用控制器按钮图形等。
一旦目标得以维持，预计到达时间： 3-4 周
2500 美元/月 - 一名全职开发人员 - 快到了！
这笔每月捐款将允许该项目的创始人 gdkchan 全职开发 Ryujinx。
5000 美元/月 - 额外的全职开发人员 - 尚未满足
这笔每月捐款将允许额外的 Ryujinx 团队开发人员全职从事该项目。
所以事不宜迟，让我们进入这个月的进展吧！
Vulkan进展：
事不宜迟，让我们进入 Vulkan 后端的一些更有趣的更改、修复和添加！
最终幻想 VII 在 AMD 卡上有一个相当……独特的视觉故障：
最终幻想
如果你有一段时间没有玩过 FF7，它并不意味着看起来像那样。 幸运的是，这包含在我们的修复列表中，这仍然是一个小问题，但要好得多：
最终幻想
雷顿教授分享了一个类似的问题：
雷顿教授
在主拉取请求下载中默认禁用直接 SPIR-V（Vulkan 的着色语言）编译以使测试更容易，但这并不意味着在本报告中被遗忘了！ gdkchan 一直在努力修复着色器后端的大量错误，并开始支付一些可观的红利。
SPIR-V 着色器的 。 编译速度比目前在 OpenGL 上使用的 GLSL 着色器快得多 查看下面的比较（都没有任何缓存）：
OpenGL GLSL 与。 Vulkan SPIR-V：
很酷吧？ 值得一提的是，OpenGL 视频使用完全多线程编译，而 Vulkan 仅使用单线程编译！ 这就是 SPIR-V 的强大之处，我们可能会在下一份报告中分享更多关于并行编译的内容。
荒野之息是我们的第一个案例研究。 许多更喜欢冒险的用户正在使用一款游戏来检查他们是否已经设法启用 SPIR-V，因为一些……嗯……容易发现的问题！
之前：
塞尔达传说：旷野之息
之后：
塞尔达传说：旷野之息
接下来让我们看看在最近的一些更改之前没有直接使用 SPIR-V 启动的一些游戏：
真女神转生V：
真女神转生V
怪物猎人崛起：
怪物猎人：崛起
纸片马里奥：
纸片马里奥：折纸王国
足够Vulkan了一点吗？ 我们希望您不会因为太累而无法继续，因为 Vulkan 以外的生活也受到了一些重大关注！
图形处理器
添加对渲染比例的支持到顶点阶段。
游戏有时可以在顶点阶段读取 textureSize 以告知片段着色器纹理的大小，而无需在那里查询。 以前，顶点着色器中不存在缩放来校正尺寸，因此游戏将原始放大后的纹理尺寸提供给片段着色器； 这是不正确的行为。 这样做有两个缺点需要注意：一个是片段和顶点支持缓冲区描述必须相同，因此在使用时必须定义完整大小的 scales 数组。 另一个是在使用顶点着色器纹理时必须更新片段纹理计数。
修复了在 超级马里奥派对 和 世界游戏大全51 中导致奇怪的偏移溢出的渲染比例（世界游戏大全51 在其许多游戏中仍然具有像素化外观，因为它在着色器中做了其它事情）。 这也修复了一个回归，如果你升级了 塞尔达无双:灾厄启示录 等游戏，则会出现一些线路伪影。
超级马里奥派对
超级马里奥派对
塞尔达无双:灾厄启示录
塞尔达无双:灾厄启示录
塞尔达无双:灾厄启示录
纹理同步、不兼容的重叠处理、数据刷新改进。
这是一个相当大的更新， 这个巨大的更新旨在解决由纹理修改和数据刷新引起的一系列问题，主要是在每个句柄而不是每个视图的基础上处理数据刷新，并将刷新与同步点增量同步。 它还引入了一种新的后端方法，因此它目前与 Vulkan 不兼容。
第 1 部分：同步纹理刷新
这种变化已经 酝酿 了一段时间。 当首次添加通过内存跟踪刷新纹理时，我们的 CPU 和其它各种组件要 慢得多。 GPU 与 CPU 的关系如此紧密，以至于当游戏试图访问数据时，几乎可以肯定数据已经完成并且数据会在那里，只是偶然。 这并没有持续多久，随着时间的推移，人们开始遇到各种问题，即在数据完全准备好之前纹理会被冲洗掉，从而导致出现白水：
塞尔达传说：旷野之息
喷射战士 中的彩虹灯光：
喷射战士
后端多线程和 Vulkan 的添加使情况变得更加复杂，以至于人们认为这是一种回归。
为了解决这个问题，我们需要看看在所有这些冲洗和纹理中发生了什么，以及我在写这篇文章之前必须查找的其它单词。 当游戏刷新纹理数据时，通常会有某种通知让系统知道它想要的数据是否还在。 如果不使用这个系统，那么一切都是掷骰子，最终可能会导致 CPU 和 GPU 之间的竞争。 虽然这在纸面上听起来很酷，但在实践中它是一场噩梦并且最终是未定义的行为，因此对后端进行了一些更改以确保：在比赛中， GPU 总是获胜。
第 2 部分：不兼容数据的刷新排序
截至目前，Ryujinx 遵循纹理缓存的核心假设，其中纹理的使用在其自己的 布局 格式 （想象这为 shape size ）。
这个核心假设通过不刷新或加载“垃圾”数据来保持重要的纹理数据处于活动状态，同时节省时间。 听起来不错吧？ 好吧，这里是踢球者：这条规则之前并没有完全建立起来，而且一如既往，每条规则都有例外......
问题在于不兼容的纹理只有在出现新的叠加层时才有可能被删除，并且只有 在创建纹理时 。 如果两个纹理同时存在于缓存中，它们可以分别刷新......以任何顺序。
这就是新规则发挥作用的地方。 简单地说，如果一个纹理被写入，而其他一些纹理试图使用它的内存，它们的数据被认为是无效的。 这意味着一次只能存在一个，因此数据刷新将始终使用最新的可用信息。 问题解决了！ 请注意，这些规则之前已经存在，它们只是在创建时强制执行，而不是在每次使用时强制执行。 这是一个影响每场比赛的巨大彻底变化。
第 3 部分：刷新主机不兼容的格式
稍微切换一下，有时会使用不完全支持的纹理格式或关系。 两个这样的例子是：
ASTC 压缩纹理，桌面 GPU 不支持（具有讽刺意味的英特尔 iGPU 除外）。
BCN 压缩的 3D 纹理，OpenGL 不支持（但 Vulkan 可以支持）
Ryujinx 通过将它们转换为 CPU 上受支持的未压缩格式来支持这些格式。 但是，这意味着不能直接在 GPU 上访问数据，这对于……渲染内容非常重要。 正如任何人都可以猜到的那样，这并不理想，并且导致了整个 主机 的问题。
奇异人生：本色 和其它 虚幻4 引擎的游戏可能使用 ASTC 纹理来处理角色和环境：
奇异人生：本色
BotW 绘制压缩的 3D BCn 纹理以用于蓝色溶解瞬移动画：
之前，由于 Ryujinx 无法移动此纹理的数据，Link 会立即消失。 修复此问题的更改不是最快的，但它是完全兼容的，并且允许我们覆盖以前完全损坏的情况，以及将来的某个时候，允许支持不支持 BCn 的平台，如移动硬件。
奇异人生：
塞尔达旷野之息：
因此，在相当长的部分之后，让我们一起看一些漂亮的图片。
塞尔达传说：旷野之息
喷射战士 2 不会自行播放，并在整个地图上溅起彩虹（不确定这是 W 还是 L）：
喷射战士2
我们都在这里吸取了教训。 我自己现在知道，如果你在riperiperi 不断喊 “CEMU MILK WATER GX2DRAW DONE” ，他可能会解决气候危机，如果它让你闭嘴！ 在某种程度上，他做到了。 海拉尔的水又干净了。
修复采样的多重采样纹理大小
渲染目标和复制纹理的宽度/高度已经被驱动程序预乘以用于多重采样纹理。 对于池中的着色器采样纹理，它们不会被预乘。 除了允许纹理具有正确的大小（因为传递给后端的 TextureCreateInfo 具有宽度和高度除以样本量）。
修复了 大神 HD 上的渲染。
大神：绝景版
实现 IMUL、PCNT 和 CONT 着色器指令，修复 FFMA32I 和 HFMA32I
Ryujinx 能够运行各种自制应用程序，尽管有些可能不如其它应用程序运行得好。 MelonDS，一个 Nintendo DS 模拟器向我们介绍了我们之前不知道的 IMUL、PCNT 和 CONT 着色器指令，最后两个类似于现有的 PBK/BRK 和 SSY/SYNC 。对， 在实现这些时，FMUL32I 指令的实现在修改过程中得到了修复，因此第三个操作数应该使用目标寄存器，而不是“SrcC”，因为该指令不存在。与上述问题类似的问题HFMA32I 也是如此，但指令表中也缺少这个，因此已修复。
修复被检测为不兼容重叠的相邻 3d 纹理切片
Texture Sync 带来的巨大变化相当大，但出现了一些问题，导致 异度之刃 游戏出现奇怪的颜色分级。 基本上发生的事情是大多数切片的渲染 3D 纹理数据都丢失了。
当尺寸不匹配时修复渲染目标清除
在 OpenGL 和 Vulkan 上，当绑定的渲染目标具有不同的大小时，它只会在所有大小的交集处渲染。 在 GPU 上，此剪辑由 ScreenScissorState 寄存器对控制。 这个寄存器以前大部分被忽略，但是对于清除，如果绑定了不同大小的渲染目标，并且游戏试图清除其中一个，并且屏幕裁剪大小与被清除的目标匹配，这可能会导致问题。 OpenGL 会将其裁剪为最小尺寸并且不会清除整个区域。 此问题已通过强制解除所有其它渲染目标来解决，以避免主机剪辑，然后使用根据屏幕裁剪和用户裁剪 (0) 计算的自定义裁剪区域。
修复了没有完全清除屏幕的 Pathway。
添加 BGRA 格式的功能
这增加了一个称为 SupportsBgraFormat 的新功能。 在 OpenGL 上，它总是错误的，因为 API 不支持 BGRA 纹理格式。 但是，它将在 Vulkan 上设置为 true，这允许我们在那里使用这些格式，而无需自己在片段着色器输出上交换组件。 这里的主要目标是减少 Vulkan 分支和当前分支之间的差异，从而使审查变得更加容易。
停止使用 glTransformFeedbackVaryings 并在着色器上使用显式布局
在 Nintendo Switch 上，当在 OpenGL 上启用该功能时，有两种方法可以指定应该写入变换反馈缓冲区的内容。 第一个也是我们当前使用的一个是传递要使用 glTransformFeedbackVaryings 函数写入的着色器输出的名称。 较新的方法是使用布局限定符直接在着色器上指定它。 此更改实现了后者。 原因是 Vulkan 只支持后者，Vulkan 上没有“TransformFeedbackVaryings”函数来指定着色器之外的信息。 实际上，此更改的代码大部分来自 Vulkan 分支。 因此，这里的主要优势是减少了与 Vulkan 和 Master 的差异，这将使审查更容易，并允许我们在两个 API 上使用相同的方法。 这种新方法的一个限制是，例如，不可能将相同的输出写入多个缓冲区（尽管可以创建多个输出并复制值）。 但由于游戏还必须指定变换反馈布局，它们也应该受到同样的限制。
修复完成 0 次绘制时 GPU 计数器报告的死锁
Nintendo Switch 上的一些游戏使用所谓的条件渲染，如果条件为真或假，游戏会在其中渲染不同的用户界面 (UI) 标记。 有时，Ryujinx 上会出现一个罕见的错误，即报告包含 0 次绘制的区域的计数器可能会使 GPU 死锁。 如果此写入与跟踪操作重叠，那么 GPU 最终可能会等待它打算在未来执行的操作，因此它只会卡住。 之前，这会立即报告并将结果从后端线程写入客户内存（跟踪）。 启用后端线程时，不允许后端线程触发在 GPU 上等待的读取操作，因为它最终可能会等待自己，并且永远不会前进。 在后端多线程的 SyncMap 的情况下，它将尝试等待尚未完全存在的后端同步对象，因为同步对象根据 GPU 和跟踪将存在，但尚未由后端创建。 修复方法是像任何其它事件一样将 0 绘制事件排队，它的 _bufferMap 值只是强制为 0，并且它将与计数器队列上的其它事件一起刷新。
这修复了带有条件渲染的问题游戏，例如超级马里奥奥德赛、马里奥赛车 8、喷射战士 2
添加对 BC1/2/3 解压的支持（用于 3D 纹理）
巨大的纹理同步更新增加了对使用不受支持的压缩格式刷新不兼容重叠的支持。 但是，仅支持 BC4 和 BC5 压缩格式。 这扩展了它以支持 BC1、BC2 和 BC3 格式。 这修复了在 OpenGL 上使用具有 3D 纹理的格式的游戏中损坏的纹理。 Vulkan 没有这个问题，因为它支持 3D 压缩格式。 其它更改包括，添加了新的“Supports3DTextureCompression”功能，在 OpenGL 上始终为 false，但在 Vulkan 上应设置为 true，更改了 GpuContext 上的 Capabilities 属性以返回 struct ref 以避免复制，还将 Capabilities 结构属性更改为只读字段，以及避免复制。
删除了 Bc1Rgb 格式。 它们没有被使用（实际上它们非常没用，因为 RGB 和 RGBA 变体之间没有区别，除了忽略 alpha 分量（可以通过将 swizzle 上的 alpha 设置为 1 来完成）），最后优化了现有的 BC4 和 BC5减压器也是如此。 BC4 在这里大约快 2.5 倍，而 BC5 大约快 2.1 倍（使用随机生成的 256x256x2 3D 纹理进行测试）。
修复了 Vesperia 故事中的文本。
修复了 异度之刃 2 中的爆炸。
异度之刃2
修复顶点着色器中未更新 res 缩放参数
在 Ryujinx 之前，当平面数组上的比例在技术上相同时，渲染比例数组不会更新，但顶点比例的起始索引不同。 当顶点阶段具有绑定并且片段阶段绑定计数自上次渲染比例更新以来已更新时，这通过更新支持缓冲区中的比例来解决问题。
为 16 字节/4 字的信号量版本添加时间戳。
《塞尔达传说：旷野之息》有一个错误，游戏会在 Ryujinx 中以 20 fps 的速度运行，如果是全速运行，则超过该速度会使其超过其原生帧速率。 这是不正确的行为，这是一个长期存在的错误，只是因为问题很奇怪而难倒了开发人员。 事实证明，游戏在信号量释放后读取了一个 ulong 8 字节：这是它试图进行性能计算的时间戳，所以它只在必要时才写入。
这修复了 塞尔达传说：旷野之息 一直被限制在 20fps（现在它只在游戏运行太慢时才会这样做）。
CPU/HLE/内核
ffmpeg：添加额外的检查和错误消息
一些游戏使用 H264 视频编码，通过 ffmpeg 上下文显示给用户。 如果系统没有安装正确的软件包，Ryujinx 会在空值错误中崩溃，这当然不理想！
这增加了一些错误检查和日志记录，以通知用户如果他们没有安装所需的包，最重要的是防止“随机”崩溃。
CPU - 实现 FCVTMS（矢量）
我们仍在寻找新旧游戏，它们让 ARMeilleure（Ryujinx 的 CPU 动态重新编译器）步入正轨。
此更改实现了 FCVTMS 矢量 CPU 指令，该指令允许 XCOM 2 等游戏现在启动。 与无休止的 CPU 指令的斗争仍在继续……
更新到 LibHac 0.15.0
LibHac 更新通常伴随着大量的错误修复和新游戏，由于文件系统的准确性提高，这些新游戏现在将启动！
然而，这次新版本相当于一次大扫除，对代码进行了一些*和一些小改动。 这些更改旨在使我们的开发人员以及最终我们的用户对文件系统代码的未来更新更加无缝。
sfdnsres：实现 NSD 解析
修复了在几个网络相关服务“GetAddrInfoRequest”和“GetHostByNameRequest”请求时缺少 NSD 使用的实现。
这只是本报告中的众多网络修复之一！
禁用访客 Internet 访问时返回 DNS 解析错误
事实证明，一些游戏，尤其是 古惑狼4 时机已到，会在启动过程的早期尝试连接到服务器。 在此修复之前，如果禁用访客网络选项，游戏将立即崩溃，因为它将无法查找 DNS 并继续出错。
如果禁用允许崩溃再次成功启动的设置，此更改将返回到旧行为。
sfdnsres：阻止与 NPLN 服务器的通信尝试
最近互联网上到处都是任天堂正在用新的“NPLN”服务器替换他们老化的“NEX”服务器系统！ 也许下次粉碎可以回滚……
怪物猎人：崛起 等一些游戏是最早部分使用这个新系统的游戏之一，当然很快就会有更多游戏出现。 此更改只是将新服务器添加到内部 DNS 阻止列表中。
帐户：重做 LoadIdTokenCache 以自动生成随机 JWT 令牌
许多 Switch 服务器使用 JWT（json Web 令牌）进行身份验证。 JWT 是一种在服务器之间传递信息而不将其存储在数据库中的简单且标准化的方式。
这提高了 Ryujinx 在使用此调用时的准确性，并使其更接近硬件实现。
bsd：修改 API 并使套接字抽象
你们有些人知道，有些人不知道，Ryujinx 是一个已有 4 年历史的项目，因此一些代码库已经有一段时间没有出现了。 想想4年前你在哪里！
由于网络修复在 1 月初风靡一时，是时候再次冒险突破漏洞并返回 API 和套接字功能。 此处的更改、更新和现代化列表非常广泛，其一些亮点包括：
套接字实现与 IClient 类分离（如果需要，将来允许可能的套接字本地实现）
IClient 的 IPC 代码已修改为使用更现代的内存 API
ssl：实现 SSL 连接
SSL，或者对于我们没有网络背景的读者，“安全套接字层”是一种用于在联网计算机之间建立加密链接的协议（这与在 https 网站上为您提供小挂锁的协议相同！）。
一些应用程序需要经过 SSL 身份验证的连接来启动/显示 Switch 和扩展 Ryujinx 的内容。 其中包括一些游戏，尤其是现在可以正常运行的 Twitch 等应用程序。
修复 32 位标题的返回类型不匹配
在几个月前在 CPU 重新编译器中进行了优化的尾部合并后，由于地址是 32 位而不是 64 位，可能会出现一个小问题，即返回类型可能与函数的实际返回类型不匹配。这个然后会在游戏上引起中断并引起混乱！
此更改解决了中断和导致它的问题。
内核：修复在中断处理程序中固定时的死锁
即使是我们中最优秀的人也会犯一些看起来相当严重的小错误。 一个简单的错位关键部分导致某些游戏陷入僵局，例如 怒首领蜂大复活 和可能的其它游戏。
幸运的是，只需要对 2 行代码进行基本的重新调整，这很快就得到了纠正！
图形用户界面/杂项
添加金手指管理器
金手指是电子游戏不可或缺的一部分，我们的一位开发人员认为它也应该是 Ryujinx 不可或缺的一部分。 在此更改之前，金手指在技术上已经运行良好，但它们总是被全面应用，用户无法在运行时切换它们或从大列表中选择他们想要激活的金手指，这 可以 通过金手指管理器进行切换。
此更改实现了我们自己的金手指管理器，它将解析您的金手指文件并允许在运行时有选择地启用这些文件。 使用 Actions -> Manage Cheats 在游戏中尝试一下（只要确保您首先正确放置了一个有效的金手指文件！）。
实施模拟摇杆范围修改器
没有手柄是完美的，无论 PlayStation 用户如何努力说服您，因此随着时间的推移，他们的模拟摇杆会像其它所有东西一样受到磨损。 死区调整可以帮助减轻摇杆的漂移，但就像人类在老年时一样，有时这些旧手柄无法达到与过去相同的最大值。
范围修改允许在轴上更早地达到控制器的“最大”输入，以帮助旧的或设计奇特的手柄输入完整的方向。 像 任天堂明星大乱斗 特别版 这样的游戏需要完整的输入才能持续冲刺，因此这一变化也有助于即使是全新的控制器更轻松地执行此类技术。
结束语：
到目前为止，2022 年对我们来说已经是非常多事的一年！ 本报告的最后一部分可能会让您对网络术语感到无聊，但它确实允许 Nintendo Direct x Ryujinx 交叉！
自从我们谈到我们在 Avalonia 中的 UI 重写已经有一段时间了，但我们想向每个人保证，进展仍然很强劲，甚至还有时间让其中一些变得非常漂亮！
新的UI
手柄设置窗口
我们要感谢大家一直以来的支持，我们希望能够在下个月为您带来更多（准时）信息！
