多好的一年啊。上尉，现在才八月。
七月发生了如此多的事情，以至于感觉比微不足道的31天要漫长得多。一个新的异种刃，数码兽(是的，你们都是)，帕特里翁的目标终于实现了；我们真的有一个月的时间去回忆。那么，我们为这份进展报告准备了什么呢？我们有一个所有变化的常规纲要，一点关于AMD的讨论(最近看起来像一个片段)，还有，不要忽视大象，一个大标志要求你阅读专门的Vulkan博客帖子！
没有必要再拖延了，所以在我们开始之前，请看看我们的patreon目标。
帕特里翁目标:
Vulkan GPU后端-合并！
我们为此专门写了一篇博文，所以请查看一下这里！
ARB着色器-目标于2021年4月达成。
工作正在进行中，请再等一会儿，直到我们能够将此更新交付到我们满意的状态。
ARB着色器将通过使用OpenGL API提高NVIDIA GPUs上的着色器编译速度，进一步减少第一次运行时的停顿。
GPU:
分辨率缩放修复让我们在这个月出门，riperiperi解决了一个特别恼人的bug，当缩放某些Unity游戏时，例如Hat in Time和Cruis'n Blast。当缩放超过原生分辨率时，这些游戏会在屏幕上留下红色污点，这使得缩放这些游戏有点像一把双刃剑。幸运的是，这里的解决方案很简单避免缩放这些反叛纹理同时继续扩展其他一切。


血腥的一夜...

我地板上的污渍！
SD高达战斗联盟演示在发布时启动，但不幸的是在游戏中崩溃。原因被追踪到DMA线性纹理复制的快速路径中的一个错误，但是由强制FindTexture方法只匹配带有确切的复制高度，游戏现在启动，看起来功能很好。

我们如何管理样本池的问题终于在这个月出现了，在Super Zangyura中表现不佳。考虑到游戏的视觉基础，它在现代硬件上努力达到30FPS是一个惊喜。纹理池缓存的硬限制是4，这意味着如果一个游戏需要使用更多的缓存，4个缓存中的一个将被删除，并需要在需要时重新创建，这将导致创建时的一些主要性能下降。通过创建一个采样器池缓存和更好地评估何时池可以被安全地处理，在超过4的限制的游戏中的性能大大提高。大多数游戏只使用一个单一的纹理池，所以不要期望这会影响到这个以外的地方。

补2楼

JUMP FORCE Deluxe是一款已经如此接近现在，唯一剩下的主要视觉缺陷是场景中出现的大绿灯。

这里的问题是着色器上的一个简单的数据丢失错误。由于解码器在某些情况下不考虑分支指令，生成的着色器代码将跳过一些重要信息。通过修正这一遗漏，gdkchan终于给这个特殊的棺材钉上了钉子。

关于大光源可能不应该出现的话题:东京海市蜃楼会议有相当重要的意义，我们可以说，太阳活动导致游戏实际上无法进行。这是游戏使用的bloom的问题，也是生成的着色器的问题。通过支持有条件退出，我们的视网膜得救了！


太阳耀斑

补6楼：

新的怪物猎人崛起DLC需要一些困难的变化来渲染，这正在逐步推出。第一个是通过将无绑定消除扩展到与常量句柄结合的着色器，允许游戏到达其闪屏。

第二种方法通过以下方式修复了新日光防护DLC中的闪烁扩展着色器优化器以传播phi节点。不幸的是，我们这里没有图像对比，因为即使渲染游戏也需要更多的WIP修改。希望在未来的报告中会有一个完整的DLC包的前后对比！
自着色器缓存2.0以来，积压的一些旧更改终于能够完成，包括将alpha添加到覆盖抖动中。对于任何不知道的人来说:“抖动”指的是计算机图形中的一种效果，其中物体或纹理看起来有斑点:

在复古电子游戏中，这是用来增加深度，否则泥泞的纹理；它最终变得非常标准化，成为当摄像机移动到后面以保持玩家在视野中时使固体物体看起来半透明的一种方式。
神奇宝贝传奇阿尔宙斯在树木和岩石等环境模型上使用抖动，但以前这种效果没有被模拟，因为它需要新着色器格式中引入的新着色器专门化。gdkchan试图在缓存重写之前修复这个问题，但是如果没有着色器专门化，抖动仿真将需要出现在每个单独的片段着色器上，即使着色器永远不会使用它。这些问题是所有这些都在这个新的实现中解决了。

我看见你了...
DMA处理程序中的一些冗余分配也被删除这个月，这可能会导致一些小的优化，在FMV(全运动视频)播放，由于较低的GC播放期间口吃。这里的结果很难衡量，但这有望消除视频播放中的一个简单瓶颈。
为了结束GPU部分，我们使用了piddling添加Vulkan后端。不太大，这里没有严重的变化，只有40，000行代码。如果你问我们的话，这是新手的数字。无论如何，如果你想听到更多的这个话题，请查看完整的博文！
这flatpak需要快速更新以确保它不会在选择Vulkan和we now时崩溃避免为未使用的常量缓冲区添加着色器缓冲区描述符；这个改变也会影响OpenGL，但可能会对Vulkan的性能有一点影响。
CPU/服务:
7月还带来了一些新的CPU和服务修复、实现和存根；首先是几个BSD(网络套接字)修复。DontWait标志现在可以在“Recieve”方法中使用在这种情况下现在处理通过网络交换的字节大小选项。第二个变化是新发布的超级马里奥奥德赛在线mod部分要求的，并修复了《神性原罪2》中的崩溃回归。

当我们试图仿真整个交换机时，有一些服务是大多数用户甚至不会想到PC仿真器的。其中之一是名副其实的“GetTemperature”服务，你可能已经猜到了，它以摄氏度为单位报告交换机的内部温度。该服务导致家酿启动器在引导期间崩溃，因为它试图探测此数据。这存根设置42度的恒温摄氏度(显然是69度…)，这似乎满足了家酿啤酒的环保需求。

随着Switch上门户集合的发布，在我们的服务和CPU仿真中都发现了两个问题。首先是我们的Vi服务不准确通过gdkchan的RE快速解决，第二个是FCVT半到双转换指令的实现。
留下的明天继续。

今天继续
随着这些变化，门户1和2都启动了，其中门户1基本上没有bug。传送门2仍然有一些图形问题，对象剔除时，他们不应该。


用户界面:
7月，用户界面开发在街上很热，尽管没有多少普通用户会看到这种情况。到目前为止，我们已经多次提到了我们向Avalonia的转移，最近我们指出了该项目的第1部分正在被合并。
好了，第1部分可以离开了，因为July合并了第2部分和第3部分，从而使新的UI与当前的GTK实现不相上下。
第二部分实现了完整的设置窗口:

第三部分添加了剩余的上下文窗口:

虽然这些都是核心的改变，但是它们为任何贡献者现在可以带来的修复、添加和调整打开了闸门。项目文件已被清理一次, 两次至少对生活质量进行了调整.
这包括为所有项目启用“分层编译”。与被认为是“本机”的GTK相比，Avalonia是一个完全“JITed”的框架，这意味着。NET运行时通常要在第一次运行时做大量的工作，即使是在程序编译之后；分层编译允许。NET来启动应用程序，而不需要应用所有的代码优化，从而加快GUI启动时间，减少应用程序的延迟。随着程序启动越来越频繁。NET可以随着时间的推移逐渐开始执行这些优化，而不是一次全部转储。GTK也启用了这一功能，但作为一个“本地”框架，GTK不需要像Avalonia那样在GUI启动上做那么多工作。我们第一次运行Avalonia应用程序时，发现时间从14秒减少到了3秒。
“提前”编译也完成了与分层编译类似的任务，通过将一些首次运行成本转移到编译过程中来减少延迟。这种方法的缺点是文件大小增加了3倍，开发团队认为这个成本对于分层编译的小改进来说太大了。
既然功能对等已经实现，Emmaus(首席UI开发人员)也已经开始脱离GTK。这用户配置文件编辑器现在使用单个内容对话框而不是每个选项都有新的单个窗口。这意味着更加流畅的体验，减少了打开和关闭窗口之间的混乱和延迟，也为未来的数据管理器(a保存经理已经在进行中)。

除此之外，还做了许多其他的更改，包括:
A 几处语法错误到工具提示和选项，包括GTK.
阿瓦隆尼亚的工具提示被修改然后回传至GTK。
这简体中文区域设置已更新和繁体中文补充。
边框被添加到弹出菜单中。
错误修复到鼠标输入, 显示控制台开关，以及光标隐藏得到了实施。
的解决方法允许菜单项在点击时可切换而不仅仅是在他们的复选框中添加了(当Avalonia解决这个疏忽时将被删除)。
修正了一个程序会崩溃的错误当试图切换控制器mid映射时。
正如你可能看到的，这一切都刚刚开始，我们已经有一个更长的错误和问题列表需要解决，然后Avalonia才能成为默认的UI，每个人都可以在启动时看到它。一旦这些问题得到解决，改变更新程序的过程就会开始，为你提供所有新的UI项目，而不是旧的。现在，你必须保持耐心，让它成为无缝体验的工作仍在后台继续！

补13楼

杂项/基础设施:
把我们排除在这个月的变化之外。我们项目的基础设施和生活质量进行了一些重大修改，包括:
确保我们首先加载最新的FFmpeg库(避免因过时的依赖关系而崩溃)。
为Windows完全移除FFmpeg依赖性包装我们自己的绑定。
重新许可和重定格式琉金克斯。音频项目到麻省理工学院的许可与项目的其余部分一致。这是上述“分层编译”功能与我们的许可兼容所必需的。
分辨率缩放现在可以通过热键调整。默认为未映射，但在合并Avalonia时将是可映射的，或者当前可以通过直接编辑Ryujinx数据文件夹中的“config.json”来映射。
一个特别的变化，你们中的很多人会感兴趣的是非正式地称为“Windows 11 FixTM”。用户注意到，在更新到Windows 11时，Ryujinx在一些游戏中变得几乎无法播放，因为大而持续的口吃会无缘无故地降低FPS。

由于Horizon操作系统的运行方式，像Windows这样的操作系统需要绕过许多奇怪的地方才能做到准确无误；其中之一是我们需要映射4Kb大小的内存。Windows 11似乎有一个独特的缺陷，这个过程有时可能需要数百的时间比在Windows 10上长，我们仍然不知道这是为什么。
经过将内存取消映射处理程序移动到本机处理程序我们可以大幅减少这些有问题的4Kb映射的数量，从而挽救Windows 11的困境。
"嘿，Ryujinx团队，我们听说AMD最终修复了他们的OpenGL驱动程序？"
它终于发生了。AMD已经承认了OpenGL的存在。你可以想象这是一个值得庆祝的日子。我们点了披萨，开了香槟，分享了在《超级马里奥奥德赛》中AMD GPUs只能处理13FPS的黑暗日子的幸福回忆…

虚空在召唤...
等等，什么？不仅它仍然是坏的，而且AMD不知何故也设法打破了奥德赛的渲染？Siggghhhhhhhhhhhhhh
回到更严肃的讨论:它并不像在SMO上看到的那样糟糕，在一些游戏中，我们不得不承认AMD在某些情况下对OpenGL的显著改进。

那些读过我们的Vulkan博客的人应该对这个图表很熟悉，但是这里增加了“NGL”数据集，你可以把它理解为AMD新的22.7.1驱动程序的“新GL”。在我们测试的所有地方，性能都受到了影响，奇怪的是，除了SMO，那里的性能和图形渲染都出现了倒退。马里奥赛车8豪华版有很大的性能提升，但同样遭受全新的视觉缺陷。

耀西的晚间巡回赛
Vulkan仍然是AMD GPU系统的最佳选择，但至少OpenGL在某些游戏中是一个可行的选择。Metroid Dread实际上是一个异常值，比旧驱动程序增加了269%，甚至比Vulkan提高了143%(尽管我们相当肯定这只是由于API瓶颈，因为即使是Nvidia也在这个标题中看到了更好的OpenGL性能)。
不管怎样，我们希望这能澄清这个问题。我们很高兴AMD终于完成了某物来解决他们的性能障碍，但这只是许多改进的第一步。声称OpenGL是“固定的”还为时过早，我们都希望AMD继续关注剩下的性能问题，渲染错误和缺乏扩展(这也适用于Vulkan！).
结束语
差不多就是这样！对于那些正在寻找Xenoblade Chronicles 3新闻的人来说，你必须等到下个月，但它的要点是，目前Vulkan上有随机崩溃，OpenGL在着色器编译方面非常慢，你几乎无法观看一些过场动画！除此之外，性能似乎很好，但我们还不能称之为愉快的发挥。你可以查看兼容性报告这里.
仿真器是在数千小时的工作基础上构建和维护的，包括从逆向工程、CPU和GPU仿真、服务HLE，一直到UI和UX。我们的大门永远向任何有兴趣投身于开关仿真和C#前沿的真正独特项目的人敞开。如果这听起来有点像你的茶，那么看看我们的开源代码库或者加入或者不调和.
下个月再见！