Update index.md

site/content/entry/yuzu-progress-report-may-2023/index.md

@@ -66,6 +66,7 @@ This caused massive slowdowns during gameplay, as the transfer operation of goin
 Collecting memory in VRAM is much faster than transferring data over to system RAM.
 So, instead of relying on the slow shared memory, the memory manager (Reaper) now {{< gh-hovercard "10288" "keeps everything in dedicated memory" >}} (VRAM), leaving some free space to accommodate sudden spikes in VRAM usage when new assets are loaded.
 If you see 2GB or more of always-free VRAM in your system, know that its purpose is to keep gameplay smooth, even on 4GB GPUs.
+Don’t worry, we’re not wasting your precious VRAM. We’re just keeping it warm and cozy for when you need it.
 This also has the added benefit of saving on system RAM consumption, allowing 8GB RAM users to have more stable gameplay.
 
 All of this is not enough to allow 4GB VRAM users or less to achieve stable gameplay, so it’s time to reveal the ace up yuzu’s sleeve.
@@ -77,18 +78,19 @@ Ladies and gentlemen, we present you `ASTC recompression`, a {{< gh-hovercard "1
 	"./astcrecomp.png| We recommend to avoid BC1 if possible."
   >}}
 
-The principle is simple, add an extra recompression step, from ASTC > RGBA8, to ASTC > RGBA8 > [BC1 or BC3](https://en.wikipedia.org/wiki/S3_Texture_Compression).
+The principle is pretty simple, we just add one more step to the recompression process, from ASTC > RGBA8, to ASTC > RGBA8 > [BC1 or BC3](https://en.wikipedia.org/wiki/S3_Texture_Compression).
 
-The default `Uncompressed` setting uses the old `RGBA8` method, causing no image quality loss, but consuming the most VRAM.
+The default `Uncompressed` setting uses the old `RGBA8` method, which preserves the original image quality, but also consumes the most VRAM.
 For users that wish to emulate `Tears of the Kingdom`, we recommend setting this option if their GPU has at least 10~12GB of VRAM.
-For other, more **normal** games, this option is suitable for users with cards with at least 4GB of VRAM.
+For other, more **reasonable** games, this option is suitable for users with cards with at least 4GB of VRAM.
 
-The `BC3 (medium quality)` setting reduces the VRAM usage of ASTC textures by a factor of four, with a very minimal loss in quality, which can be spotted as softer textures.
+The `BC3 (medium quality)` setting reduces the VRAM usage of ASTC textures by a factor of four, with a very minimal loss in quality, which you can barely notice as slightly softer textures.
 This setting is recommended for emulating `Tears of the Kingdom` on 6GB and 8GB GPUs.
-For other games, this setting is suitable for GPUs with 3GB of VRAM.
+For other games, this setting is good for GPUs with 3GB of VRAM.
 
-Finally, the `BC1 (low quality)` setting will reduce VRAM consumption by a factor of eight, but will also have a significant impact on texture quality, to the point where some assets will look completely different.
-We don’t recommend using this setting, but it will allow 4GB VRAM users to play `Tears of the Kingdom` without significant issues, and will make 2GB users have a much more stable and consistent experience in other games.
+Finally, the `BC1 (low quality)` setting cuts down the VRAM consumption by a factor of eight, but will also have a significant impact on texture quality, to the point where some assets will look completely different.
+We don’t recommend using this setting, unless you really have to. 
+It will let 4GB VRAM users to play `Tears of the Kingdom` without significant issues, and will make 2GB users have a smoother and more reliable experience in other games.
 
 {{< single-title-imgs
     "From left to right, or top to bottom on phones, BC1 vs BC3 vs ASTC (Fire Emblem Engage)"
@@ -109,18 +111,19 @@ As you can see, BC1 destroys image quality in some games.
 But in others, the difference is less noticeable.
 If you only have 2GB of VRAM and 8GB of RAM, the sacrifice may be worth it.
 
-At the moment this is done using the CPU, but GPU acceleration is planned for the future.
+Right now this is done using the CPU, but GPU acceleration is planned for the future.
 We also hope to add an option to use BC7 in the future to provide a higher quality experience.
 
-Keep in mind that {{< gh-hovercard "10398" "ASTC recompression" >}} won’t affect other texture formats, so the actual VRAM usage reduction will vary per game. Not every resource held in VRAM is ASTC.
+Keep in mind that {{< gh-hovercard "10398" "ASTC recompression" >}} only works on ASTC textures, so the actual VRAM usage reduction will depend on the game. Not every resource held in VRAM is ASTC.
+If your hardware can handle ASTC natively, this setting won’t do anything for you, as there's no need for any recompression.
 
-In addition, byte[] has also {{< gh-hovercard "10422" "tuned the memory manager" >}} to be more aggressive.
+In addition, byte[] has also {{< gh-hovercard "10422" "tuned the memory manager" >}} to be more ruthless.
 This change should help improve gameplay stability during long sessions on systems with less RAM.
-yuzu always targets support for a minimum of 8GB of RAM on systems with dedicated GPUs.
+yuzu always aims to support a minimum of 8GB of RAM on systems with dedicated GPUs.
 
 He also made sure that {{< gh-hovercard "10452" "memory collection doesn’t happen during the configuration step" >}}, so that it doesn't cause a device loss (i.e. the GPU driver shutting down).
 
-By fixing the {{< gh-hovercard "10433" "block depth adjustment on slices" >}}, Blinkhawk solved the rendering issues affecting the gloom textures over the terrain in `Tears of the Kingdom`, a bug that was particularly noticeable on low VRAM hardware.
+By fixing the {{< gh-hovercard "10433" "block depth adjustment on slices" >}}, Blinkhawk solved the rendering issues affecting the gloom textures over the terrain in `Tears of the Kingdom`, a bug that was especially frustrating on low VRAM hardware.
 
 {{< single-title-imgs-compare
     "Let’s not make the gloom feel depressed… (The Legend of Zelda: Tears of the Kingdom)"
@@ -137,11 +140,11 @@ And for integrated GPU users with 16GB of system RAM or less, such as the Steam
     "./astcfix.mp4"
     >}}
 
-That ends the list of changes made to memory management to allow `Tears of the Kingdom` to be playable in at least the components listed in our [hardware requirements](https://yuzu-emu.org/help/quickstart/#hardware-requirements).
+That wraps up the list of changes made to memory management to allow `Tears of the Kingdom` to be playable in at least the components listed in our [hardware requirements](https://yuzu-emu.org/help/quickstart/#hardware-requirements).
 
-These changes would not be necessary if GPUs simply supported ASTC textures.
-Wouldn't you like your games to be no bigger than 100GB instead of having software features that degrade image quality, such as frame generation?
-Native ASTC decoding support would allow this.
+These changes would not be necessary if GPUs just supported ASTC textures.
+Wouldn't you like your games to be no bigger than 100GB instead of having software features that ruin image quality, such as frame generation?
+Native ASTC decoding support would make this possible.
 
 An Intel Iris Xe iGPU can run the game at 30 FPS in handheld mode while using less memory than any other hardware combination, all thanks to being their last GPU capable of decoding ASTC.
 More on Intel's driver support later.
@@ -150,12 +153,12 @@ More on Intel's driver support later.
 	"./totkception.png| We need to go deeper! (The Legend of Zelda: Tears of the Kingdom)"
   >}}
 
-So far, that was just the worst part of it. More work was needed to get the game to boot and render properly. Let’s expand on that.
+So far, that was just the worst part of it. More work was needed to get the game to boot and render properly. Let’s dive into that.
 
 One thing that both the Switch and Android devices have in common is the way they present to the screen.
-Google's OS uses `SurfaceFlinger` (the only good Linux presentation method), and the Switch uses `nvnflinger`, which is a custom adaptation of `SurfaceFlinger` designed for the Switch's firmware and OS.
-While this gives us a good frame of reference for how `nvnflinger` should be emulated, sometimes, bugs can still slip through.
-These bugs are not always obvious, especially if no game had rendering problems until now.
+Google's OS uses `SurfaceFlinger` (the only good Linux presentation method), and the Switch uses `nvnflinger`, which is a custom adaptation of `SurfaceFlinger` designed for the Switch's firmware and operating system.
+While this gives us a good frame of reference for how `nvnflinger` should be emulated, sometimes bugs can still sneak in.
+These bugs are not always easy to spot, especially if no game had rendering problems until now.
 
 byte[] realised that yuzu was {{< gh-hovercard "10236" "serialising binder responses incorrectly" >}} (in a different way to how Android does it).
 Fixing this simple bug allowed for `Tears of the Kingdom` to boot.
@@ -172,11 +175,11 @@ Next is a bug that only affected the base game. Following updates were unaffecte
 	"./red.png| Ganon likes to record Link… (The Legend of Zelda: Tears of the Kingdom)"
   >}}
 
-This magical red dot on the bottom right was caused by {{< gh-hovercard "10243" "incorrectly tracking" >}} render target indexes when clearing.
-Thanks to some behaviour changes made by Maide, Link is no longer being recorded.
+This mysterious red dot on the bottom right was caused by {{< gh-hovercard "10243" "incorrectly tracking" >}} render target indexes when clearing.
+Thanks to some behaviour changes made by Maide, Link is no longer being spied on.
 
-After the game was released, several users reported that the date in the game's save files was consistently being set to 1 January 1970.
-After checking the behaviour of the Switch, byte[] implemented {{< gh-hovercard "10244" "a few changes" >}} that solved the issue, with an updated service implementation which allows for computing the time in nanoseconds, automatically adjusting for clock skew, and using the same clock source as the system’s steady clock.
+After the game was released, several users reported that the date in the game's save files was always being set to 1 January 1970.
+After checking the behaviour of the Switch, byte[] implemented {{< gh-hovercard "10244" "a few changes" >}} that solved the issue, with an updated service implementation that allows for computing the time in nanoseconds, automatically adjusting for clock skew, and using the same clock source as the system’s steady clock.
 
 There were also reports of graphical glitches when using the 2X resolution scaling factor: Link and terrain textures would become corrupted after switching weapons.
 
@@ -184,10 +187,10 @@ There were also reports of graphical glitches when using the 2X resolution scali
 	"./2x.png| Scrambled textures. (The Legend of Zelda: Tears of the Kingdom)"
   >}}
 
-Blinkhawk quickly identified the cause of this problem: wrong clears were being done in the code responsible for synchronisation in the buffer cache.
+Blinkhawk quickly found the cause of this problem: wrong clears were being done in the code responsible for synchronisation in the buffer cache.
 {{< gh-hovercard "10249" "Some tweaks," >}} and the game can be safely played while scaled.
 
-For the Linux AMD users, specifically people using older Mesa RADV Vulkan driver releases, byte[] found out that one of the features of `VK_EXT_extended_dynamic_state3`, dynamic depth clamp, was implemented incorrectly in the driver, leading to vertex explosions in some expository moments in the game.
+For the Linux AMD users, especially people not using the latest Mesa RADV Vulkan driver releases, byte[] found out that one of the features of `VK_EXT_extended_dynamic_state3`, dynamic depth clamp, was implemented incorrectly in the driver, leading to vertex explosions in some expository moments in the game.
 
 {{< single-title-imgs-compare
     "Oh, there goes the vertex… (The Legend of Zelda: Tears of the Kingdom)"
@@ -208,7 +211,7 @@ The green glow had a pixelated look, caused by {{< gh-hovercard "10402" "missing
 
 Several keyboard strokes later, and byte[] went green with envy.
 
-Next on the list of peculiar rendering issues is one that affected camera changes — for example, when talking to an NPC, or aiming with the bow/throwing a weapon.
+Next on the list of weird rendering issues is one that affected camera changes — for example, when talking to an NPC or aiming with the bow/throwing a weapon.
 Large areas in front of the player would go black for a frame and then return to normal.
 Needless to say, it was very distracting.
 
@@ -217,7 +220,7 @@ Needless to say, it was very distracting.
   >}}
 
 This bug was caused by the way the {{< gh-hovercard "10418" "texture cache" >}} processed aliases and overlaps, which were in the wrong order and caused sync problems.
-After a few attempts by Blinkhawk and byte[], the issue was finally solved.
+After a few tries by Blinkhawk and byte[], the issue was finally fixed.
 
 While investigating bugs related to `Tears of the Kingdom`, a copy-paste error hidden in the code for 3 years was also found.
 In the shader recompilation code, [Rodrigo](https://github.com/ReinUsesLisp) copied over the wrong value from one line to the next.
@@ -236,7 +239,7 @@ In an interesting case where a UI setting is needed for improving a game’s gam
 	"./remove.png| It’s fun to watch the game reconstruct the images in real time."
   >}}
 
-This option is needed because using Asynchronous shader building in `Emulation > Configure… > Graphics > Advanced` will break fused weapon icons in the weapon selection menu, as well as autobuild history.
+This option is needed because using Asynchronous shader building in `Emulation > Configure… > Graphics > Advanced` will mess up fused weapon icons in the weapon selection menu, as well as autobuild history.
 
 {{< single-title-imgs-compare
     "Not even close, baby! (The Legend of Zelda: Tears of the Kingdom)"
@@ -244,7 +247,7 @@ This option is needed because using Asynchronous shader building in `Emulation >
     "./cachefix.png"
     >}}
 
-Disabling Asynchronous shader building and clearing the cache storage lets the game properly rebuild the images of all your weaponized monstrosities.
+Disabling Asynchronous shader building and clearing the cache storage lets the game properly rebuild the images of all your weaponized abominations.
 
 That’s the progress so far with `The Legend of Zelda: Tears of the Kingdom`!
 You may have noticed there are no performance improvements mentioned here.
@@ -252,10 +255,10 @@ We’re following one of the most important rules of coding, “Make it work. Ma
 
 As this is a particularly popular game (and for good reason), here are some recommendations that user reports and fixes have taught us.
 
-- This game is very taxing on hardware. What we list in yuzu’s `recommended` [hardware requirements](https://yuzu-emu.org/help/quickstart/#hardware-requirements) is the minimum needed to sustain 30 FPS in most areas. A 6-core desktop Zen 2/11th gen Core, 16GB of RAM, and a GPU with at least 6GB of VRAM are the baseline for now.
+- This game is very demanding on hardware. What we list in yuzu’s `recommended` [hardware requirements](https://yuzu-emu.org/help/quickstart/#hardware-requirements) is the minimum needed to sustain 30 FPS in most areas. A 6-core desktop Zen 2/11th gen Core, 16GB of RAM, and a GPU with at least 6GB of VRAM are the baseline for now.
 - The latest CPUs (Zen 4/13th gen Core, always speaking of desktop products) provide massive improvements in IPC, RAM bandwidth and cache sizes. Where a Ryzen 7 5800X3D barely manages 55 FPS, a Ryzen 5 7600 reaches 90 FPS.
 - Normal GPU accuracy can be used to improve performance safely.
-- The Depths are particularly taxing on VRAM. Remember to use ASTC recompression if you are VRAM starved. We recommend at least 8GB of VRAM for 2X resolution scaling using BC3 compression.
+- The Depths are particularly hungry for VRAM. Remember to use ASTC recompression if you are VRAM starved. We recommend at least 8GB of VRAM for 2X resolution scaling using BC3 compression.
 - The modding community has been providing amazing mods. Dynamic framerate, improved resolution and details, and much more is only a few clicks away. Here’s a [collection with recommendations](https://github.com/HolographicWings/TOTK-Mods-collection).
 - Old FPS mods compatible with the base version of the game (1.0.0) are unstable and will cause softlocks and crashes during certain actions like the Game Over screen. Update your game and use newer mods.
 - Remember to test the game without mods before reporting issues, as mods are still altering memory regions to work.
@@ -270,39 +273,38 @@ As this is a particularly popular game (and for good reason), here are some reco
 That’s right, with the blessing from Skyline’s [bylaws](https://github.com/bylaws), and Dolphin’s [t985](https://github.com/t895), the help from Citra’s [GPUCode](https://github.com/GPUCode), and work from yuzu’s and Citra’s [flTobi](https://github.com/FearlessTobi), [bunnei](https://github.com/bunnei), [Merry](https://github.com/merryhime), [Flamboyant Ham](https://github.com/Schplee), [german77](https://github.com/german77), and more, yuzu is now available for Android devices!
 
 We recommend you to read the detailed article on yuzu Android [here](https://yuzu-emu.org/entry/yuzu-android/).
-What we're going to do here is explain the direction we will take from now on, help with settings and hardware requirements, and set the expectations for what's possible at the moment.
-And pardon us if the tone is aggressive, but we learned from [previous experiences](https://kotaku.com/ps2-emulator-android-aethersx2-developer-death-threats-1849955012) from within the Android emulation community that things need to be explained firmly and precisely.
+In this section, we will give you an overview of our future plans, some tips on settings and hardware requirements, and a realistic outlook on what you can expect from yuzu on Android right now.
+And pardon us if the tone is aggressive, but we learned from [previous experiences](https://kotaku.com/ps2-emulator-android-aethersx2-developer-death-threats-1849955012) from within the Android emulation scene that we need to be clear and direct.
 
-The Android version of yuzu took almost eight months of development time. 
-Right now, it is basically the desktop version under the hood with an Android UI, with *very few* platform optimisations applied.
-This means goodies like 32-bit game support, NVDEC video decoding support, motion, controller automapping, resolution scaling, and filters are available.
-On the other hand, features like updates, DLC, mods and cheats management, LDN, and the controller configuration applet are still in development.
-The plan is to slowly but surely get the Android builds to feature parity with the PC version.
+The Android version of yuzu was not an easy feat. It took us almost eight months of hard work to make it happen. 
+Right now, it is essentially the same as the desktop version under the hood, with an Android UI and *very few* platform-specific tweaks.
+This means you can enjoy features like 32-bit game support, NVDEC video decoding support, motion, controller automapping, resolution scaling, and filters are available.
+On the other hand, features like mods and cheats management, LDN, and the controller configuration applet are still under development.
+Our goal is to gradually bring the Android builds up to speed with the PC version.
 
-Besides the Google Play Store, we will soon be uploading releases to our GitHub, and F-Droid is also planned.
+In addition to the Google Play Store, we will soon be posting releases on our GitHub, and F-Droid is also on the horizon.
 
 {{< imgs
 	"./lime1.png| Don’t judge, it’s a light game and loads quickly, it was great for testing. (Sakura Neko Calculator)"
   >}}
 
-As a team, our biggest takeaway from Project Lime is that, even 8 years after the release of the NVIDIA Tegra X1 (the SoC the Nintendo Switch uses), Android SoC vendors have never learned how to make GPU drivers.
+One of the biggest lessons we learned from Project Lime is that, even after 8 years since the launch of the NVIDIA Tegra X1 (the SoC that powers the Nintendo Switch), Android SoC vendors still don’t know how to make GPU drivers.
 
-Everyone started the Vulkan driver development race at the same time in 2016.
-And yet, to date no SoC vendor other than NVIDIA has a compliant and stable Vulkan Android driver.
+They all started working on Vulkan drivers around the same time in 2016. And yet, none of them have managed to deliver a compliant and stable Vulkan Android driver, except for the rare few NVIDIA devices.
 
-It is very clear that only 4 vendors know what they are doing in the Vulkan driver space: NVIDIA, AMD, and Mesa, with an honourable mention for Intel, who started taking this seriously very recently.
+It is obvious that only 4 vendors have the expertise and the commitment to make Vulkan drivers work: NVIDIA, AMD, and Mesa, with a special mention for Intel, who recently stepped up their game.
 
-The only option available we had to make yuzu work on Android without spending several months modifying our GPU code to accommodate all the quirks and broken extensions of Android phones and tablets was Qualcomm.
-Not because their driver is particularly good — it’s bad.
+The only viable choice we had to make yuzu run on Android without spending several months modifying our GPU code to accommodate all the quirks and broken extensions of Android phones and tablets was Qualcomm.
+Not because their driver is decent — it’s bad.
 But it was just good enough to get some games to render, albeit incorrectly most of the time.
 
-Qualcomm is the best option (and for now, the only one) because bylaws made [AdrenoTools](https://github.com/bylaws/libadrenotools), allowing users to load the ***vastly*** superior [Mesa Turnip](https://docs.mesa3d.org/drivers/freedreno.html) drivers on their Adreno 600 series GPUs, providing accurate rendering, on par with the quality expected of PC products.
-Any Qualcomm SoC named “Snapdragon ###” from the 460 to the 888+ equipped with an Adreno 600 series GPU can select to use either the proprietary Qualcomm driver, or Mesa Turnip.
+Qualcomm is the best option (and for now, the only one) because bylaws created [AdrenoTools](https://github.com/bylaws/libadrenotools), which lets users load the ***vastly*** superior [Mesa Turnip](https://docs.mesa3d.org/drivers/freedreno.html) drivers on their Adreno 600 series GPUs, providing accurate rendering, comparable to the quality expected of PC products.
+Any Qualcomm SoC with a name like “Snapdragon ###” from the 460 to the 888+ equipped with an Adreno 600 series GPU can choose to use either the proprietary Qualcomm driver, or Mesa Turnip.
 
-The performance boost you can get from a device equipped with a Snapdragon Gen 1 or Gen 2 is more than considerable.
-But the problem is that, while the included Adreno 700 series GPU is very capable hardware-wise, the proprietary Qualcomm driver for it is mediocre at best, and Mesa has only just recently started working on [adding support](https://gitlab.freedesktop.org/Danil/mesa/-/commits/TEST/turnip/a7xx-basic-support) for Turnip.
-It will be at least weeks, if not months, before we start to see proper support take shape.
-In the meantime, we plan to work on improving the rendering on the official Adreno drivers.
+The performance gain you can expect from a device with a Snapdragon Gen 1 or Gen 2 is quite significant. 
+But the problem is that, while the Adreno 700 series GPU that comes with it is very powerful hardware-wise, the proprietary Qualcomm driver for it is subpar at best, and Mesa has only just begun to work on adding support for Turnip.
+There's an early driver release to test, but results are not great for now.
+It will take weeks, if not months, before we see proper support emerge. In the meantime, we intend to work on improving the rendering on the official Adreno drivers.
 
 {{< single-title-imgs
     "Try several, don’t marry the first one that works. Divorcing a shader cache isn’t fun."
@@ -310,56 +312,55 @@ In the meantime, we plan to work on improving the rendering on the official Adre
     "./driver2.png"
     >}}
 
-The Adreno 500 series is too old for yuzu. Its proprietary Vulkan driver lacks many of the necessary features needed, and Turnip has no plans to support it either.
+The Adreno 500 series is too outdated for yuzu. Its proprietary Vulkan driver is missing many of the essential features required, and Turnip has no plans to support it either.
 
-Mali is an example of good hardware being limited by the quirks of its available drivers. 
-Unlike Adreno, Mali has no viable Mesa alternative to save it, and the current proprietary Mali drivers are in bad shape for Switch emulation.
+Mali is an example of good but weak hardware being limited by the quirks of its available drivers. 
+Unlike Adreno, Mali has no viable Mesa alternative to resque it, and the current proprietary Mali drivers are in bad shape for Switch emulation.
 Its current status is that it won’t boot any game on yuzu, but:
 
 {{< single-title-imgs
-    "Internal dev build, work-in-progress in getting Mali running."
+    "Internal dev build, work-in-progress in getting G series Mali running."
     "./mali.jpg"
     "./mali2.jpg"
     >}}
 
 We’re working on solving all the quirks needed to get Mali rendering on yuzu as soon as possible.
-This is the most popular GPU vendor on the platform after all.
-Mali support will happen, we just need some breathing room.
+This is the most common GPU vendor on the platform after all.
+Mali support will happen, we just need some time.
 
 The last case of hardware that should work, but doesn’t, is the AMD RDNA2-based Xclipse 920 from Samsung, used only in the latest Exynos 2200 SoC, and somehow completely skipped from the S23 series phones.
 Available information suggests that it may just be an old AMD Windows driver ported to Android, but for some reason the devices refuse to start rendering on yuzu.
-This is a GPU we want to get working, as there is no clear reason why it refuses to work, while desktop AMD products work almost perfectly.
-Unfortunately, we haven't yet been able to track one down, but we'll update with more info once we do.
+This is a GPU we want to get working, as there is no clear reason why it doesn't to work, while desktop AMD products work almost flawlessly.
+Unfortunately, we haven't yet been able to get our hands on one, but we'll update with more info once we do.
 
-For all other vendors like PowerVR, Vivante, etc: don't even try.
-These vendors provide such poor quality drivers that support is out of the question.
+For all other vendors like PowerVR, Vivante, etc: don't bother.
+These vendors offer such low quality drivers that support is impossible.
 
-We’re working hard on improving GPU compatibility, adding the required changes needed to boot within the limitations set by the vendors.
+We’re working hard on improving GPU compatibility, adding the necessary changes needed to boot within the limitations set by the vendors.
 
-CPU emulation still uses the Dynarmic JIT, instead of native code execution. 
+CPU emulation still relies on the Dynarmic JIT, instead of native code execution. 
 This allows us to run 32-bit games like `Mario Kart 8 Deluxe`, but is slow for 64-bit games.
-Expect “good” compatibility, comparable to the desktop version thanks to this, but at the same time, low performance and high temperatures.
+Expect “good” compatibility, similar to the desktop version thanks to this, but also low performance and high temperatures.
 Native code execution, or NCE (do I smell `Project Nice`?) is on our list of goals for the Android builds.
 
-The CPU itself, while very critical for performance and the main bottleneck for now, is second in importance to the GPU, for the reasons previously mentioned.
+The CPU itself, while very crucial for performance and the main bottleneck for now, is less important than the GPU, for the reasons previously mentioned, its drivers.
 The same rules as on PC apply here: 6 cores or more is preferred, and the highest possible IPC is strongly recommended. A Snapdragon 8 Gen 2 can be twice as fast as a Snapdragon 865.
 
 RAM use is both a blessing and a curse.
-A blessing because Android devices natively support ASTC textures — the format is intended for such devices.
+A blessing because Android devices natively support ASTC textures — the format is designed for such devices.
 This allows the GPU to use very little RAM, just like on the Switch.
 
-The curse is that, because Android is such a heavy OS, there is no guarantee that complex games will run on devices with 6GB of RAM.
-8GB is the strong recommendation, which puts compatibility on the expensive side of the spectrum.
-A certain Zelda game we spent a lot of words on currently requires at least 12GB of RAM to run.
+The curse is that, because Android is such a heavy OS, there is no guarantee that complex games will run on devices with 6GB of RAM. 8GB is the strong recommendation, which puts compatibility on the pricey side of the spectrum. 
+A certain Zelda game we wrote a lot about currently requires at least 12GB of RAM to run.
 
 There are ongoing efforts to reduce memory requirements, such as native code execution and UMA optimisations for the GPU code, but the reality is that emulation adds overhead and Android will only get fatter over time.
 We may be able to get light 2D games running on 4GB devices, but we don't expect complex 3D games to run on less than 8GB any time soon, if ever.
 
 We have set the minimum required operating system to Android 11. 
-This decision was taken to cut off installation on completely unviable hardware (like Adreno 500 series devices or older Mali GPUs), and to reduce low-memory devices as much as possible.
+This decision was made to prevent installation on completely unsuitable hardware (like Adreno 500 series devices or older T series Mali GPUs), and to reduce low-memory devices as much as possible.
 This is final, as there are no plans to support older Android versions.
 
-Needless to say, it must be a 64-bit Android 11 or newer; just like on desktop, 32-bit devices will never be supported.
+Of course, it must be a 64-bit Android 11 or newer; just like on desktop, 32-bit devices will never be supported.
 
 Users with capable hardware stuck on older Android versions can either build yuzu themselves and remove the code responsible for performing this check, or install custom ROMs such as [LineageOS](https://lineageos.org/) to get unofficial Android updates on their device.
 
@@ -367,7 +368,7 @@ Users with capable hardware stuck on older Android versions can either build yuz
 	"./lime2.png| Your writer will enjoy playing visual novels and simple platformers. (The Liar Princess and the Blind Prince)"
   >}}
 
-With the depressing reality of Android software and hardware out of the way, let’s focus on the current experience.
+Now that we have covered the harsh reality of Android software and hardware, let’s focus on the current experience.
 
 We included a customisable input overlay with haptics, which can be disabled if you prefer to play with a Bluetooth Xbox controller, Sony Dualshock 4 or Dual Sense, or a Nintendo Pro Controller, and a framerate counter.
 You can access these settings in-game by dragging from the left side of the screen.
@@ -404,7 +405,7 @@ This makes importing and exporting saves very simple. Thank you!
 	"./saves.png| It’s dangerous to go alone, take this!"
   >}}
 
-One important thing to remember: Android has the most… peculiar file system permissions.
+One important thing to remember: Android has the most… unusual file system permissions.
 We recommend creating a yuzu folder on your storage root to store your keys in, to avoid any permissions issues.
 
 You can get different Adreno and Turnip driver versions to test from [here](https://github.com/K11MCH1/AdrenoToolsDrivers/releases).
@@ -429,9 +430,9 @@ Because this isn’t just a Zelda emulator after all.
 Who wants more `Project Y.F.C.` goodies?
 Blinkhawk serves us {{< gh-hovercard "10155" "Reactive Flushing" >}}, with fries.
 
-In the early days of yuzu, if the CPU read an area modified by the GPU, full sync flushing between the host and guest GPU (emulated and system’s GPU) would trigger, let’s call it, “old reactive flushing”.
-This was safe and provided proper rendering, but was also incredibly slow.
-So Blinkhawk replaced this system for predictive flushing some years ago, improving performance considerably but introducing with it several graphical regressions, like broken shadows and lighting, wrong thumbnails on saves and photos, and even vertex explosions.
+In the early days of yuzu, if the CPU reads an area modified by the GPU, full sync flushing between the host and guest GPU (emulated and system’s GPU) would trigger, let’s call it, “old reactive flushing”.
+This was safe and provided proper rendering, but was also slow.
+So Blinkhawk replaced this system with predictive flushing some years ago, improving performance significantly but introducing with it several graphical regressions, like broken shadows and lighting, wrong thumbnails on saves and photos, and even vertex explosions.
 
 With this release of the yuzu fried chicken, Blinkhawk introduces the new reactive flushing, which has the following fixes:
 
@@ -707,13 +708,13 @@ But first, we have some progress in the Maxwell and Pascal situation.
 
 In the past, we used to recommend users to stick to older driver releases for the GTX 750/900/1000 series, as anything newer than the 470 driver series was unstable.
 Thanks to the work done with the garbage collector for `Tears of the Kingdom`, we now know that the problem with these cards is how the driver handles out-of-memory situations.
-We were even able to observe it on Turing cards with 4GB, so it wasn't unique to older cards, we just didn't have a game that utilised VRAM as much as Zelda.
+We were even able to observe it on Turing cards with 4GB, so it wasn't unique to older cards, we just didn't have a game that used VRAM as much as Zelda.
 
 We reported our findings to NVIDIA with a test case, so it’s in their hands now.
 
-As the VRAM fills up, an AMD card will get slower and slower until it stops working and crashes yuzu, while an NVIDIA GPU would corrupt the entire desktop, taking all the displays with it.
+As the VRAM fills up, an AMD card will get slower and slower until it stops working and crashes yuzu, while an NVIDIA GPU would corrupt the entire desktop, taking all the displays with it, sometimes even forcibly rebooting the system.
 
-Using the ASTC recompression option goes a long way to avoiding this problem.
+Using the ASTC recompression option helps a lot to avoid this problem.
 But if it does happen, it can still cause a system lock or reboot, so we need a way to mitigate this while NVIDIA investigates the issue.
 
 {{< single-title-imgs-compare