Apply suggestions from code review pt3

Co-authored-by: Schplee <24275329+Schplee@users.noreply.github.com>
This commit is contained in:
Matías Locatti 2021-10-11 04:41:06 -03:00 committed by GitHub
parent 8b2163fda9
commit 6bedbdf0f0
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -26,7 +26,7 @@ Booting a title in Linux with the Vulkan API using the Intel Mesa driver resulte
The problem was in the synchronization between the rendering and subsequent presentation of frames.
Previously, yuzu would issue the Vulkan `Present` command, then wait for the frame to be rendered before continuing with the process.
While this was fine for other drivers and vendors, ANV (Intels Vulkan driver) expected to have the frame already rendered before this command, which caused this error.
While this was fine for other drivers and vendors, ANV (Intels Vulkan driver) expected to have the frame already rendered before this command, causing this error.
epicboy fixed the synchronization behaviour so that
[yuzu now waits until the frame is fully rendered and ready before presenting it](https://github.com/yuzu-emu/yuzu/pull/6953).
@ -86,7 +86,7 @@ texture, and a Z axis used to determine which texture of the array is in use.
TL;DR, one is a sphere and the other is a list.
Vulkan allows for marking textures to be converted into cube maps later if needed, but the sampling (reading) is determined by the texture type specified by the games shader
Vulkan allows for textures to be marked for conversion into cube maps if later needed, but the sampling (reading) is determined by the texture type specified by the games shader
instructions. This type is then passed to the graphics API.
We do just this and the game decides to keep its textures as arrays, which is its own decision.
However, the AMD driver decides that the textures should be sampled as cube maps, ignoring what the texture view determined just before.
@ -223,7 +223,7 @@ View the results below:
## General bugfixes
epicboy noticed a memory leak that would grow progressively after stopping and restarting the emulation, which was caused by yuzus `main_process` not being cleaned up.
[By destroying this process when stopping emulation ](https://github.com/yuzu-emu/yuzu/pull/7009), the resources are properly freed now, fixing the leak.
[By destroying this process when stopping emulation](https://github.com/yuzu-emu/yuzu/pull/7009), the resources are properly freed now, fixing the leak.
Additionally, epicboy also mitigated the crashes that happened when emulation was stopped by
[using std::jthread for worker threads](https://github.com/yuzu-emu/yuzu/pull/7019).
@ -261,7 +261,7 @@ Moving on to a quality-of-life change, some games pop-up a confirmation window w
"./exit.png| Like this, End emulation confirmation window"
>}}
This kind of redundant question is made by the game itself and while we always had a toggle to skip it, it wasnt working properly. epicboy comes to the rescue,
This kind of redundant question is generated by the game itself and while we always had a toggle to skip it, it wasnt working properly. epicboy comes to the rescue,
[fixing the toggle](https://github.com/yuzu-emu/yuzu/pull/6997) for good and saving us precious seconds in quitting our games.
If you wish to change this behaviour, the option is in `Emulation > Configure… > General > Confirm exit while emulation is running`.