Flam review

Co-authored-by: Schplee <24275329+Schplee@users.noreply.github.com>

site/content/entry/yuzu-progress-report-dec-2022/index.md

@@ -6,7 +6,7 @@ coauthor = "GoldenX86"
 forum = 0
 +++
 
-Hello yuz-ers. What a year! We ended 2022 with more yuzu Fried Chicken, Vulkan changes, a new input driver, too much kernel work, more performance, better visuals, and much more!
+Hello yuz-ers. What a year! We ended 2022 with more yuzu Fried Chicken, Vulkan changes, a new input driver, an exorbitant amount of kernel work, more performance, better visuals, and much more!
 
 <!--more--> 
 
@@ -17,12 +17,12 @@ Basically an abridged version of what is expected for the full “Part 2” rele
 The changes in this pull request include a rework of the `MacroHLE` implementation to include various new macros for indirect draws and configurations.
 
 As discussed in previous articles, macros are small GPU programs that implement features like indirect and instanced draws. They must be emulated.
-MacroHLE (High-Level Emulation) is the process of avoiding executing a requested macro and translating it directly to the code that it would have generated (like an instanced or indirect draw).
+MacroHLE (High-Level Emulation) is the process of avoiding executing a requested macro and instead translating it directly to the code that it would have generated (like an instanced or indirect draw).
 This works in contrast and in parallel with MacroJIT, which works by actually emulating the loops and control flow contained in macro programs in a [just-in-time](https://en.wikipedia.org/wiki/Just-in-time_compilation) fashion.
 
 Now, why keep both? Well, each one performs their own specialized task.
 MacroHLE's advantage compared to MacroJIT has to do with the emulation of indirect calls.
-An indirect call such as a draw, uses data generated somewhere in the GPU through some shader in order to establish the draw parameters and its draw count.
+An indirect call, such as a draw, uses data generated somewhere in the GPU through some shader in order to establish the draw parameters and its draw count.
 Traditionally with MacroJIT we had to sync the Host GPU and Guest GPU to obtain the indirect data in order to execute the macro correctly. 
 With MacroHLE, we create an indirect draw command in the host GPU that points to the translated address of where the GPU generated data should be. 
 Thus skipping the syncing.
@@ -30,10 +30,9 @@ Thus skipping the syncing.
 Thanks to these improvements, yuzu now is able to more efficiently execute macros, considerably reducing CPU overhead, and without having to change any setting.
 What we internally like to call a “passive skill”.
 
-As a result of these changes, performance has been improved in several titles, including those developed by Koei Tecmo, `Pokémon Scarlet and Violet`, `Bayonetta 3`, and `Monster Hunter Rise` (with the exception of version 12.0.0, which still requires further fixes).
+As a result of these changes, performance has been improved in several titles, including those developed by Koei Tecmo, `Pokémon Scarlet and Violet`, `Bayonetta 3`, and `Monster Hunter Rise` (with the exception of version 12.0.0, which still requires further fixes) to name a few.
 The crashes in `Fire Emblem: Warriors` have also been fixed.
-We measured a 5-20% performance boost in select titles. 
+We measured a 5-20% performance boost in select titles, but the improvement may be higher on CPUs with a lot of cache. From our testing, the 5800X3D can reach over 30% in some games.
-May be higher on CPUs with tons of cache, from our testing, the 5800X3D can reach over 30% in some games.
 The performance cost of rendering at higher resolutions was also greatly reduced.
 
 {{< imgs
@@ -44,10 +43,10 @@ But the goodies don’t end here! Blinkhawk also added support for the `VK_EXT_e
 
 This relatively “new” pair, along with the already implemented `VK_EXT_extended_dynamic_state` and `VK_EXT_vertex_input_dynamic_state`, are the four extensions responsible for considerably reducing shader building stuttering.
 But as it always goes, support for these extensions in consumer GPUs is spotty at best, and a mess to support at worst.
-State3 in particular is only supported by the [NVIDIA Vulkan Beta](https://developer.nvidia.com/vulkan-driver) drivers, version 527.86 at the time of writing, and recent (late 2021 and newer) RADV Mesa drivers.
+`State3` in particular is only supported by the [NVIDIA Vulkan Beta](https://developer.nvidia.com/vulkan-driver) drivers, version 527.86 at the time of writing, and recent (late 2021 and newer) RADV Mesa drivers.
 We recommend anyone interested in testing how a fresh shader cache performs to give these drivers a go.
 
-Not like there is an alternative, implementing these extensions forced us to perform another dreaded cache invalidation.
+With no alternative, implementing these extensions forced us to perform another dreaded cache invalidation.
 
 {{< imgs
 	"./dynamic.png| Proof that the best GPUs for yuzu continue to be NVIDIA for either OS, or AMD on Linux"
@@ -56,21 +55,21 @@ Not like there is an alternative, implementing these extensions forced us to per
 Most drivers cover at least 3 of the 4 extensions without issue, one way or another, with one glaring exception, AMD Windows drivers.
 The price of this is higher stuttering during gameplay when new shaders are being processed compared to running the same card on Linux with RADV, or using any other brand.
 
-A small side-note, Linux RADV users should update their Mesa version to the latest (or use a more recent distro version if needed), as support for state2 was broken on versions before 21.2.
+A small side-note, Linux RADV users should update their Mesa version to the latest (or use a more recent distro version if needed), as support for `state2` was broken in versions before 21.2.
 
 As a last second change, Blinkhawk tested removing the 16-bit floating point (FP16) blacklist enforced on NVIDIA Ampere and newer GPUs (RTX 3000 series and higher). If it worked, it would have allowed them to work similarly to Turing and AMD Radeon offerings in this aspect. However, NVIDIA redesigned how their FP32 and FP16 units operate on Ampere and newer, with both providing identical performance. Unfortunately, even if it were faster, it'd be irrelevant in the end, as FP16 on Ampere and Ada is still bugged in the drivers, producing graphical issues in many games.
 
 All irrelevant in the end as the precision of FP16 on Ampere and Ada is still bugged in the drivers, producing graphical issues in many games, and even if we re-enabled it, there is no performance benefit thanks to the specific design of these cards, they are already fast enough with FP32.
 
-The only remaining architecture that could benefit from enabling blacklisted FP16 support is Intel on Windows, but their drivers are a dumpster fire regarding this aspect, so they continue to emulate 16-bit precision with 32-bit the same way as Ampere and Ada. In this case with its always present performance loss. 
+The only remaining architecture that could benefit from enabling blacklisted FP16 support is Intel on Windows, but their drivers are a dumpster fire regarding FP16. So they continue to emulate 16-bit precision with 32-bit the same way as Ampere and Ada, in this case with its always present performance loss. 
-Had to be, the weakest architecture that could benefit the most out of this change, is the only one that remains broken…
+_Of course_ the weakest architecture that could benefit the most from this change is the only one that remains broken…
 
-Another extra benefit of this iteration of Y.F.C. is that Normal GPU accuracy is much more safer to use. 
+Another extra benefit of this iteration of `Y.F.C.` is that `Normal` GPU accuracy is much safer to use. 
-Particles will continue to be better in High, but games like `Pokémon Scarlet/Violet`, `Bayonetta 3`, and many others can be played with Normal accuracy without glitches much more regularly (Bayonetta 3 in particular still needs High for its title screen, but gameplay is safe on Normal), with the included big performance benefit this incurs.
+Particles will continue to be better in `High`, but games like `Pokémon Scarlet/Violet`, `Bayonetta 3`, and many others can be played with `Normal` accuracy without glitches much more regularly with the big performance benefit this provides (`Bayonetta 3` in particular still needs `High` for its title screen, but gameplay is safe on `Normal`).
 
 ## Other awesome GPU changes, and yet more cache invalidations
 
-The month doesn’t stop there, there has been a plethora of changes worth mentioning too on our GPU codebase.
+The month doesn’t stop there, there has been a plethora of changes worth mentioning too in our GPU codebase.
 
 Oh boy, [byte[]](https://github.com/liamwhite) sure has been busy this month.
 
@@ -81,8 +80,8 @@ But that’s not the whole story, so let’s elaborate further.
 
 [BreadFish](https://github.com/breadfish64) implemented the original OpenGL version, intending to release it as part of the [resolution scaler](https://yuzu-emu.org/entry/yuzu-art/). Turns out implementing SMAA for Vulkan is no joke, and after being nagged by your writer, byte[] had to work 2 weeks to get it in shape.
 
-SMAA, being based on MLAA, intends to be a post-processing (aka shader based) option focused on quality over performance by analyzing adjacent pixels, unlike good boy FXAA who just blurs the entire screen.
+`SMAA`, being based on `MLAA`, intends to be a post-processing (aka shader-based) option focused on quality over performance by analyzing adjacent pixels, unlike `FXAA` which just blurs the entire screen.
-The SMAA filter is implemented using render passes, and it produces its best results when combined with FSR filtering. 
+The `SMAA` filter is implemented using render passes and it produces its best results when combined with FSR filtering. 
 AMD recommends properly anti-aliasing the image in their official Overview Integration Guide.
 The results speak for themselves:
 
@@ -93,7 +92,7 @@ The results speak for themselves:
 	>}}
 
 {{< single-title-imgs
-    "Ropes and power lines, the classical example for anti-aliasing testing (Pokémon Scarlet)"
+    "Ropes and power lines, the classic example for anti-aliasing testing (Pokémon Scarlet)"
     "./svnoaa.png"
     "./svfxaa.png"
     "./svsmaa.png"
@@ -108,6 +107,7 @@ The results speak for themselves:
 
 For those interested, we used the `ULTRA` preset, testing showed a low performance loss even with a GT 1030, so we preferred to focus on quality.
 Only users with old integrated GPUs should avoid SMAA. For the rest, it’s a safe option to turn on and forget.
+You can find the feature in `Emulation > Configure > Graphics > Anti-Aliasing Method`.
 
 {{< single-title-imgs-compare
 	"SMAA doesn’t suffer from the horrible colour banding of FXAA (The Legend of Zelda: Breath of the Wild)"
@@ -115,7 +115,6 @@ Only users with old integrated GPUs should avoid SMAA. For the rest, it’s a sa
 	"./botwsmaa.png"
 	>}}
 
-You can find it in `Emulation > Configure > Graphics > Anti-Aliasing Method`.
 
 {{< imgs
 	"./all3.png| A close-up to finish (Xenoblade Chronicles 3)"
@@ -132,7 +131,7 @@ although the issue persists at other values. byte[] continues working on the iss
 	"./off1fix.png"
 	>}}
 
-The change also addresses an issue with the erroneous rendering of water in the game `Super Mario Sunshine` with automatic anisotropy on Lavapipe (mesa, Linux), although the error still occurs at other anisotropy values.
+The change also addresses an issue with the buggy water rendering in `Super Mario Sunshine` with automatic anisotropy on Lavapipe (mesa, Linux), although the error still occurs at other anisotropy values.
 
 {{< single-title-imgs-compare
 	"Kind of makes it look even older (Super Mario Sunshine)"
@@ -146,9 +145,9 @@ Previously, when the guest requested a cache invalidation, the implementation wo
 
 On the side, he also {{< gh-hovercard "9372" "promoted various Vulkan Extensions to use core methods." >}} In the Vulkan API, vendor extensions are optional features provided by specific hardware vendors or drivers that may not be available on all systems. In contrast, core methods are a fundamental part of the Vulkan specification and are guaranteed to be available on all systems that support the API. Thus, promoting extensions to use core methods can improve their reliability and portability.
 
-byte[] made further {{< gh-hovercard "9393" "initialization tweaks to the Vulkan API." >}} These changes included the restoration of `VK_KHR_timeline_semaphore` and `VK_EXT_host_query_reset`, which were mistakenly removed in a previous PR. He also added the flag `VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR` to the `VkInstanceCreateInfo` structure for `MoltenVK` to allow MoltenVK to be detected as an available Vulkan device.
+byte[] made further {{< gh-hovercard "9393" "initialization tweaks to the Vulkan API." >}} These changes included the restoration of `VK_KHR_timeline_semaphore` and `VK_EXT_host_query_reset`, which were mistakenly removed in a previous PR. He also added the flag `VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR` to the `VkInstanceCreateInfo` structure for `MoltenVK` to allow `MoltenVK` to be detected as an available Vulkan device.
 
-Keep in mind a lot more work is needed in order to get yuzu rendering on macOS devices. This is only early preliminary work.
+Keep in mind that a lot more work is needed in order to get yuzu rendering on macOS devices. This is only early preliminary work.
 
 [vonchenplus](https://github.com/vonchenplus) has implemented the {{< gh-hovercard "9401" "draw manager for Maxwell3D" >}} with the aim of eliminating workarounds and reorganising the drawing process to more accurately enumerate the drawing behaviour. 
 As a result of these changes, the issue in `Dragon Quest Builders` where some 3D models were not rendering properly has been fixed.
@@ -163,9 +162,9 @@ As a result of these changes, the issue in `Dragon Quest Builders` where some 3D
 	"./ds.png| No armour is best armour (DARK SOULS)"
   >}}
 
-Following these changes, vonchenplus also {{< gh-hovercard "9406" "improved the code for the topology update logic" >}} so that the implementation is more accurate. This change was necessary in order to {{< gh-hovercard "9423" "implement special topologies on Vulkan." >}}
+Following these changes, vonchenplus also {{< gh-hovercard "9406" "improved the code for the topology update logic" >}} so that the implementation is more accurate. This change was necessary in order to {{< gh-hovercard "9423" "implement special topologies with Vulkan." >}}
 
-This includes support for quad strips, which require the use of triangles to simulate them, and the ability to simulate indexed and non-indexed modes.
+This includes support for `quad strips`, which require the use of triangles to simulate them, and the ability to simulate indexed and non-indexed modes.
 In non-indexed mode, a fixed mapping table is used to connect the vertices, while in indexed mode, a compute shader is used to dynamically map the original drawing indices.
 vonchenplus has also implemented support for line loops, which require the use of triangle lists to simulate them, and for polygons, which require the use of triangle fans.
 
@@ -183,13 +182,13 @@ These changes fixed the Hero's path in `Legend of Zelda: Breath of the Wild`, as
 	"./botwfix.png"
 >}}
 
-Blinkhawk has added {{< gh-hovercard "9383" "`alpha to coverage` and `alpha to one`" >}} to our Vulkan backend.
+Blinkhawk has added {{< gh-hovercard "9383" "alpha to coverage and alpha to one" >}} to our Vulkan backend.
 
-Alpha to coverage is a multisampling technique that is used to improve the quality of transparent or partially transparent pixels.
+`Alpha to coverage` is a multisampling technique that is used to improve the quality of transparent or partially transparent pixels.
 It works by blending the alpha values of multiple samples taken from the same pixel to produce a single, more accurate result.
-This can help to reduce aliasing and other rendering artefacts that can occur when rendering transparent pixels.
+This can help to reduce aliasing and other rendering artifacts that can occur when rendering transparent pixels.
 
-Alpha to one, on the other hand, is a technique that is used to improve the quality of partially transparent pixels by setting the alpha value of each pixel to a maximum of 1.0.
+`Alpha to one`, on the other hand, is a technique that is used to improve the quality of partially transparent pixels by setting the alpha value of each pixel to a maximum of `1.0`.
 This can help to reduce the amount of alpha blending that needs to be performed, which can improve the performance of the rendering pipeline.
 
 These changes have fixed the shading of trees and grass problems when viewed up close or from a distance in `Pokémon Scarlet and Violet`.
@@ -206,25 +205,25 @@ In the past, yuzu would set every vertex and index count register to zero after
 {{< gh-hovercard "9353" "Changing this behaviour" >}} partially fixes the particles present in `Xenoblade Chronicles 3`. You can now more easily perform your off-seer duties.
 
 {{< imgs
-	"./xc3.mp4| Meat is on the menu!(Xenoblade Chronicles 3)"
+	"./xc3.mp4| Meat is on the menu! (Xenoblade Chronicles 3)"
   >}}
 
 ## CPU requirement changes, with free performance
 
 We don’t usually cover compilation changes here, but this time we had to do it because it affects compatibility.
 
-[Your writer](https://github.com/goldenx86) (or co-writer in this progress report, my partner did most of the work this time) has been playing with compilation flags in order to get more free performance, following previous work done by Blinkhawk some time ago.
+[Your writer](https://github.com/goldenx86) (or co-writer in this progress report, my [partner](https://github.com/kurenaihana) did most of the work this time) has been playing with compilation flags in order to get more free performance, following previous work done by Blinkhawk some time ago.
 
-Microsoft Visual C++ (MSVC, Visual Studio) is simple enough (we’ll talk about Linux later), you enable full program optimizations, optimize for performance instead of size, a bit here, a bit there, and you gain a nice 3%, but I wanted more.
+Microsoft Visual C++ (MSVC, Visual Studio) is simple enough (we’ll talk about Linux later). You enable full program optimizations, optimize for performance instead of size, a bit here, a bit there, and you gain a nice 3%, but I wanted more.
-Last month [Epicboy](https://github.com/ameerj) improved the build process, saving both time and memory. This created a “gap” big enough to enable the *Big One*, {{< gh-hovercard "9442" "Link-Time Optimizations" >}} (LTO), an optimization that in the past had to be discarded for eating all the available RAM of our buildbots.
+Last month, [Epicboy](https://github.com/ameerj) improved the build process, saving both time and memory. This created a “gap” big enough to enable the *Big One*, {{< gh-hovercard "9442" "Link-Time Optimizations" >}} (LTO), an optimization that in the past had to be discarded for eating all the available RAM of our buildbots.
 
-Windows testing went well and in some cases the performance uplift reaches up to 12%.
+Windows testing went well and in some cases the performance uplift reached up to 12%.
 The problem was Linux. LTO is aggressive by nature, and there’s no guarantee that all parts of the project will react nicely to it.
-In this case the problem was Qt, the UI looked completely garbled. 
+In this case, the problem was Qt, the UI looked completely garbled. 
 So LTO had to go, but in its place, we now require what [Dynarmic](https://github.com/merryhime/dynarmic/) already did for a while, [x86-64-v2](https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels) hardware.
 
-GCC and Clang builds will now compile assuming the features of CPUs compatible with the instruction sets that form part of x86-64-v2, the highest one being SSE4.2. 
+GCC and Clang builds will now compile assuming the features of CPUs are compatible with the instruction sets that form part of x86-64-v2, the highest one being SSE4.2. 
-This means the minimum CPU required for yuzu to work without crashing, in both Windows and Linux, is now the first generation of Core i series (500-900 series), which are almost 15 years old, and the FX and APU series from AMD, which are almost 12 years old.
+This means the minimum CPU required for yuzu to work without crashing, in both Windows and Linux, is now the first generation of Core i-series (500-900 series), which are almost 15 years old, and the FX and APU series from AMD, which are almost 12 years old.
 The performance boost on GCC and Clang is up to 7%.
 
 {{< single-title-imgs
@@ -233,56 +232,56 @@ The performance boost on GCC and Clang is up to 7%.
     "./lto2.png"
     >}}
 
-We originally wanted to enforce x86-64-v3 to get an even bigger performance boost as well as to ensure a proper level performance, as any CPU lacking AVX, AVX2, and in particular, FMA, will be ***very*** slow, no matter its clock speed or core count.
+We originally wanted to enforce x86-64-v3 to get an even bigger performance boost, as well as to ensure a minimum level of performance, as any CPU lacking AVX, AVX2, and in particular, FMA, will be ***very*** slow, no matter its clock speed or core count.
 
-No, that 8 cores Ivy Bridge Xeon you bought for 20 USD is not fast for this task.
+Yes, that means the 8 core Ivy Bridge Xeon you bought for 20 bucks is *not* fast enough for this task.
 
-The problem is that doing so would leave close to 9% of the user base out of support, according to our telemetry. 
+The problem, however, is that doing so would leave close to 9% of the user base out of support, according to our telemetry. 
-That many users is a considerable number, so we decided to wait more for this change.
+That many users is a considerable number, so we've decided to wait until more users adopt more modern CPUs before implementing this change.
-We’ll reevaluate enforcing x86-64-v3 in the future once OpenGL eventually ends up in the chopping block too.
+We’ll re-evaluate enforcing x86-64-v3 in the future once OpenGL eventually ends up on the chopping block as well.
 
 While this change would also apply for Windows, MSVC is not flexible enough to let us build for x86-64-v2, it either supports SSE2, or jumps straight to the first AVX.
 Dynarmic already manually uses x86-64-v2 extensions, so any CPU lacking SSE4.2 is considered unstable regardless of the OS in use.
 
 x86-64-v4 will not be an option for many years, mainly because Intel can’t decide if AVX-512, made by themselves, is something that their users should be allowed to actually use.
 
-If an old-school user is so strongly set on running yuzu on decades old CPUs, the Flatpak builds are still generic, or there’s always the option of building yuzu manually, setting any requirements.
+If an old-school user is so strongly set on running yuzu on decades old CPUs, the Flatpak builds are still generic, or there’s always the option of building yuzu manually, allowing you to configure any requirements.
 
 ## New Joy-Con driver and other input improvements
 
 [german77](https://github.com/german77) has done it again, giving us an amazing Christmas gift, a {{< gh-hovercard "9492" "new input driver for Nintendo controllers!" >}}
 This is an in-house development that doesn’t rely on SDL, so it gives us much more freedom to add features that weren’t previously available.
 
-The basics are covered, Single and Dual Joy-Con modes are available, Pro Controller is supported, button, stick, motion mapping works the same as before.
+The basics are covered. Single and Dual Joy-Con modes are available, Pro Controllers are supported, button, stick, motion mapping works the same as before.
-But the good part starts here, here’s all the new stuff added:
+But that's not exciting, here’s all the new stuff that was added:
 
-When opening up yuzu, the player LEDs will do a blinking pattern to signal that the emulator has taken control. Once you’re in game, the LEDs will reflect the player number.
+* When launching yuzu, the controller player LEDs will show a blinking pattern to signal that the emulator has taken control. Once you’re in game, the LEDs will reflect the player number.
-HD Rumble is fully implemented now, without differences compared to native pairings.
+* HD Rumble is fully implemented now, complete parity to pairing natively.
-The emulator can now automatically select between automatic and custom calibration profiles, avoiding stick drifting (as much as the Joy-Con can physically do, we can’t fix Nintendo’s problems) and providing much more accurate motion.
+* The emulator can now automatically select between automatic and custom calibration profiles, avoiding stick drift (as much as the Joy-Con can physically do, we can’t fix Nintendo’s problems) and providing much more accurate motion.
-Colour reading is added, now the actual colour of the controller is reflected in the UI and in games, just like on Switch.
+* Colour reading is added, now the actual colour of the controller is reflected in the UI and in games, just like on Switch.
-Amiibos can now be loaded with the Joy-Con just like you do on the Switch. 
+* Amiibos can now be loaded with the Joy-Con just like you do on the Switch. 
-The Ring Controller is now fully supported, no need for external programs.
+* The Ring Controller is now fully supported, no need for external programs.
-Preliminary support for the IR camera is done, games like `Night Vision`, `Game Builder Garage`, and `Nintendo Labo` can make use of this neat feature at the base of the right Joy-Con.
+* Preliminary support for the IR camera is done, games like `Night Vision`, `Game Builder Garage`, and `Nintendo Labo` can make use of this neat feature at the base of the right Joy-Con.
 
-All this extra accuracy adds a problem we didn’t usually face before, PC Bluetooth connections are very easy to saturate, especially on cheaper/Intel BT chipsets or areas with tons of interference.
+All this extra accuracy highlights a problem we didn’t often face before: PC Bluetooth connections are very easy to saturate. Cheaper/Intel bluetooth chipsets or areas with tons of interference are especially prone to this.
-For this reason, HD Rumble can potentially cause lag issues, depending on the user’s specific system. We recommend unmapping/disabling rumble in those cases.
+For this reason, HD Rumble can potentially cause lag depending on the user’s specific circumstances. We recommend unmapping/disabling rumble in those cases.
 
-Speaking of saturation, the IR camera may be slow in some games, the reason is that we currently implement only the image transfer mode, which saves 320x240 pictures. Some games prefer faster framerates at the cost of resolution, going as low as 40x30. 
+Speaking of saturation, the IR camera may be slow in some games. The reason being that we currently implement only the image transfer mode, which saves 320x240 pictures. Some games prefer faster framerates at the cost of resolution, going as low as 40x30. 
-Once all modes are added in, the choppy framerate will go away.
+Once all modes are added in, the choppy framerate will disappear.
 
 Amiibo data writing is a work in progress.
 
-Incredible input improvements don’t intend to end there.
+german77's desire for incredible input improvements doesn't end there.
 
-german77 implemented the {{< gh-hovercard "9369" "`mifare` service," >}} letting games read and write plain mifare tags.
+german77 implemented the {{< gh-hovercard "9369" "`mifare` service," >}} allowing games read and write plain mifare tags.
 Games like `Skylanders Imaginators` make use of this feature.
-The only thing lacking is support for encrypted read and writes.
+The only feature lacking is support for encrypted read and writes.
 
 {{< imgs
 	"./sky.png| Tagging! (Skylanders Imaginators)"
   >}}
 
-Speaking of SDL, a recent update broke the way it handled the GUID, the identifier of several controllers, including the integrated Steam Deck ones, causing many annoyances for Deck users.
+Speaking of SDL, a recent update broke the way it handled the GUID, the identifier of several controllers, including the one integrated into the Steam Deck, causing many annoyances for Deck users.
 So, with no alternative on hand, german77 had to implement a {{< gh-hovercard "9404" "custom filter" >}} to solve the issue.
 
 And lastly, as a very important quality of life change, german77 made the {{< gh-hovercard "9495" "input device list refresh automatically," >}} ensuring that yuzu detects controllers without the need for manual intervention. 
@@ -295,11 +294,11 @@ To close the section, [MonsterDruide1](https://github.com/MonsterDruide1) {{< gh
 With an update for Dynarmic and SDL2, byte[] enabled {{< gh-hovercard "9374" "support for ARM64" >}} compilation.
 This means all Switch titles can be tested on Linux ARM64 devices with compatible Vulkan drivers.
 
-As part of this effort we started implementing Flatpak support for ARM64 Linux devices. This {{< gh-hovercard "9419" "required making OpenGL optional" >}} for the build process, as Flatpak’s Qt build only supports OpenGL ES, not the full fledged OpenGL 4.6 compatibility profile we require.
+As part of this effort, we started implementing Flatpak support for ARM64 Linux devices. This {{< gh-hovercard "9419" "required making OpenGL optional" >}} for the build process, as Flatpak’s Qt build only supports OpenGL ES, not the full fledged OpenGL 4.6 compatibility profile we require.
 
 Part of these changes fixed compilation for macOS, but the situation remains the same, without MoltenVK support, nothing will be rendered.
 
-Epicboy implemented a series of changes with the goal of minimising the overhead of dynamic memory allocation, a task which involves requesting memory from the operating system, and can slow-down performance in some circumstances.
+Epicboy implemented a series of changes with the goal of minimizing the overhead of dynamic memory allocation, a task which involves requesting memory from the operating system, and can slow-down performance in some circumstances.
 
 The texture cache, in particular, was a significant contributor to this issue, as it constantly allocated and then deallocated memory when transferring textures to and from the GPU.
 To address this problem, Epicboy optimized the texture cache to {{< gh-hovercard "9490" "pre-allocate a buffer to store swizzle data" >}} and reuse it whenever possible, rather than performing a dynamic memory allocation every time this was done.
@@ -309,12 +308,12 @@ Epicboy also made similar changes to {{< gh-hovercard "9508" "optimise the `Read
 
 Additionally, he introduced a {{< gh-hovercard "9453" "`ScratchBuffer` class" >}} to act as a wrapper around a heap-allocated buffer of memory.
 
-The advantage of this class lies on the fact that it eliminates the need initialise the stored values, and the need to copy the data when the buffer needs to grow.
+The advantage of this class lies with the fact that it eliminates the need to initialize the stored values, and the need to copy the data when the buffer needs to grow.
-Thus, it would help to speed up things by minimising the amount of time spent on memory management tasks.
+Thus, it would help to speed up things by minimizing the amount of time spent on memory management tasks.
 
-german77 implemented {{< gh-hovercard "9444" "the `FreeThreadCount` info type," >}} which is needed by titles such as `Just Dance 2023 Edition` (although that game requires more changes in order to work).
+german77 implemented {{< gh-hovercard "9444" "the `FreeThreadCount` info type," >}} which is needed by titles such as `Just Dance 2023 Edition` (although that game requires additional changes in order to work).
 
-[Saalvage](https://github.com/Saalvage) noticed an error in yuzu's kernel implementation and made the necessary changes to {{< gh-hovercard "9411" "unlock thread mutex before destruction," >}} as not doing so incurs in undefined behaviour. “Here be Dragons” and all that.
+[Saalvage](https://github.com/Saalvage) noticed an error in yuzu's kernel implementation and made the necessary changes to {{< gh-hovercard "9411" "unlock thread mutex before destruction," >}} as not doing so incurs an undefined behaviour. “Here be Dragons” and all that.
 
 byte[] submitted a change that {{< gh-hovercard "9398" "improves the handling of system startup failure," >}} in order to prevent deadlocks and crashes when/if the GPU initialization fails.
 
@@ -342,24 +341,24 @@ Along with endless silent changes that don’t get mentioned here, [lioncash](ht
 
 ## User interface and audio changes
 
-There are interesting quality of life changes implemented for the user interface
+We've had some interesting user interface quality of life changes implemented!
-lioncash also made the {{< gh-hovercard "9394" "SPIR-V shader backend element translatable," >}} so it doesn’t always show in English for everyone.
+lioncash made the {{< gh-hovercard "9394" "SPIR-V shader backend element translatable," >}} so it doesn’t always show in English for everyone.
 The community effort working on translation can now take the label and update it accordingly.
 
 {{< imgs
 	"./spirv.png| We still don’t recommend using it over GLSL, but Mesa users report they enjoy it"
   >}}
 
-Some months ago, with the core timing changes, we allowed users to boot games with their framerate unlocked, after continuous requests by the community.
+Some months ago, with the core timing changes, we allowed users to boot games with their framerate unlocked after continuous requests from the community.
-As it turns out, nothing changed, several games hate booting with unlocked framerates, and the support channels get their fair share of people asking why their game doesn’t want to boot.
+As it turns out, nothing changed. Several games hate booting with unlocked framerates, and the support channels get their fair share of people asking why their game doesn’t want to boot.
 So, simple fix, {{< gh-hovercard "9425" "unlocked framerate at boot rights denied." >}}
-The hotkey is Ctrl + U by default.
+The hotkey to toggle unlocked framerate is `Ctrl + U` by default, only a small nuisance.
 
 Users reported that they couldn’t record or stream their yuzu window while in windowed mode.
 byte[] found the cause was setting the `WA_DontCreateNativeAncestors` Qt property for all platforms, instead of just for wayland.
-{{< gh-hovercard "9461" "Issue down, streamers rejoyce." >}}
+{{< gh-hovercard "9461" "Issue down, streamers rejoice." >}}
 
-Discord user piplup (with a very cute profile picture, I have to add) reported that yuzu didn’t save the device name (what you would call the console) after accessing a game’s custom configuration window.
+Discord user piplup reported that yuzu didn’t save the device name (what you would call the console) after accessing a game’s custom configuration window.
 german77 {{< gh-hovercard "9466" "fixed the issue" >}} (this particular setting lacked a custom configuration equivalent), and also fixed Qt 6 build issues while at it.
 
 Another very nice quality of life improvement made by german77 is making yuzu {{< gh-hovercard "9467" "remember the last selected directory" >}} for `Install files to NAND…`.
@@ -371,22 +370,22 @@ byte[] managed an amazing victory in the war against crashes when closing/stoppi
 	"./shutdown.png| We take longer than the Switch, but some games really love to take their time on console"
   >}}
 
-[Morph](https://github.com/Morph1984) helped make this possible by {{< gh-hovercard "9477" "hiding button dialog boxes," >}} allowing to create the dialog overlay byte[] added.
+[Morph](https://github.com/Morph1984) helped make this possible by {{< gh-hovercard "9477" "hiding button dialog boxes," >}} allowing for the creation of the dialog overlay byte[] added.
 
-Another battle fought in this front is related to homebrew apps. byte[] is responsible for {{< gh-hovercard "9486" "making them quit properly" >}} now too.
+Another battle fought on this front is related to homebrew apps. byte[] is responsible for {{< gh-hovercard "9486" "making them quit properly" >}} now too.
 
 [ChrisOboe](https://github.com/ChrisOboe) suddenly shows up with a glorious quality of life fix for the terminal-based yuzu-cmd build.
 Marking the build as a “Windows” application instead of a “Console” one {{< gh-hovercard "9485" "ensures that no empty command line window pops up" >}} needlessly.
-This can help streaming programs set up to run specific games with yuzu-cmd, as there is no sudden empty black box bothering at the front now.
+This can help streaming programs set up to run specific games with yuzu-cmd, as this prevents the sudden empty black box from appearing in front of other windows.
-Thanks!
+
-On our single audio change of this month, [Maide](https://github.com/Kelebek1) properly signals a buffer event on audio stops, fixing an early softlock that affected the Pokémon Brilliant Diamond/Shining Pearl
+For our single audio change of this month, [Maide](https://github.com/Kelebek1) properly signals a buffer event on audio stops, fixing an early softlock that affected the `Pokémon Brilliant Diamond/Shining Pearl` games.
 
 ## Future projects
 
-We’re just this early into 2023 and I already want to publish the next report, so much happened in so few days!
+We’re only a few days into 2023 and we already want to publish the next progress report. So much has happened in such a short time!
 
-Also, Blinkhaw, bunnei, and byte[] are up to something, can’t wait to tell you more.
+Also, Blinkhaw, bunnei, and byte[] are up to something, and we can’t wait to tell you more.
-And yes, there will be yet more cache invalidations.
+And yes, there will be yet more cache invalidations. All in the name of progress.
 
 That’s all folks! Expect a few but *very* critical Vulkan improvements next time, hope to see you then!