morph corrections

site/content/entry/yuzu-progress-report-oct-2020/index.md

@@ -36,14 +36,11 @@ Next on the list of fixed bugs, we have a [controller reconnection issue](https:
 
 For some games, vibrations didn't work properly, or at all. To understand why this was happening, We will need to explain a bit of what’s going on behind the curtains of abstraction, so please bear with me here.
 
-`Rumble` in the Nintendo Switch is physically generated by a pair of identical [Eccentric Rotating Mass (ERM) motors](https://en.wikipedia.org/wiki/Rotating_unbalance) that can emit a wide range of frequencies on the low and high spectrum, independently from each other. This contrasts with the approach used in other controllers, which typically have a low frequency ERM at the left side and a high frequency ERM at the right side; depending on the desired frequency band at which one wants to make those controllers vibrate, it is possible to send signals to one or the other and thus accomplish low and high frequency rumble. The Nintendo Switch also characterizes vibration in such a way that it's possible for games to distinguish between the left and right motors of different players. This is because each device has an identifier handler that is used to send the correct vibration commands to the right place.
+`Rumble` in the Nintendo Switch is physically generated by a pair of identical [Linear Resonant Actuator motors](https://en.wikipedia.org/wiki/Linear_actuator) that can emit a wide range of frequencies on the low and high spectrum, independently from each other. This contrasts with the approach used in other controllers, which typically have a low frequency [Eccentric Rotating Mass (ERM) motors](https://en.wikipedia.org/wiki/Rotating_unbalance) at the left side and a high frequency ERM at the right side; depending on the desired frequency band at which one wants to make those controllers vibrate, it is possible to send signals to one or the other and thus accomplish low and high frequency rumble. The Nintendo Switch also characterizes vibration in such a way that it's possible for games to distinguish between the left and right motors of different players. This is because each device has an identifier handler that is used to send the correct vibration commands to the right place.
 
 Prior to this PR, the functions that processed this handler information weren’t coded yet, or they were stubbed and returned incorrect information. Even with those limitations, this exceeded the capabilities of the [SDL library](https://www.libsdl.org/) (an [API](https://en.wikipedia.org/wiki/API) that yuzu uses to communicate with the hardware of the input devices), which was designed to work with generic gamepads that do not present any of these unique features of the Nintendo Switch. As a result, the rumble wasn't being processed correctly. This resulted in inaccurate behaviour, such as the lack of vibration for the controllers of players other than player one, since this handler information wasn't available for SDL to distinguish where to send the vibration signals other than for "controller 0". In order to make vibrations work as intended, [Morph](https://github.com/Morph1984) investigated how this information was characterized and implemented the functions to process these handlers, so that the vibration data could be sent to the appropriate devices and players. The addition of these functions also fixed a number of games, such as `Xenoblade Chronicles: Definitive Edition`, `Xenoblade Chronicles 2`, `Hollow Knight`, and many others that previously didn't exhibit rumble at all.
 
-Previously, some people using certain types of wireless controllers reported in-game performance losses whenever their gamepads rumbled. The problem of this issue lied in the rate at which the vibration states were being updated to these controllers, so [german77](https://github.com/german77) implemented a solution to reduce the rate to 50 Hz and filter out some of the vibrations. But it was later reported that some vibration effects were missing in games such as `Super Smash Bros. Ultimate` due to this filter, so an alternative solution was needed. For this reason, [Morph](https://github.com/Morph1984) implemented `Accurate Vibrations`, a toggle option (off by default) that switches between a full implementation and one with the effective vibration rate reduced through heuristics. If this option is disabled, the following actions are performed:
-
-- The vibration rate is limited to 100 vibrations per second, excluding vibrations with an amplitude value of 0 (which is considered as the "not vibrating" state). This rate was determined to be safe through testing by [Morph](https://github.com/Morph1984) and [Ren](https://github.com/renA21).
-- Successive state changes with the same amplitude value (i.e. identical amplitude vibrations) are excluded in order to reduce the amount of state changes sent into the device.
+Previously, some people using certain types of wireless controllers reported in-game performance losses whenever their gamepads rumbled. The problem of this issue lied in the rate at which the vibration states were being updated to these controllers, so [german77](https://github.com/german77) implemented a solution to reduce the rate to 50 Hz and filter out some of the vibrations. But it was later reported that some vibration effects were missing in games such as `Super Smash Bros. Ultimate` due to this filter, so an alternative solution was needed. For this reason, [Morph](https://github.com/Morph1984) implemented `Accurate Vibrations`, a toggle option (off by default) that switches between a full implementation and one with the effective vibration rate reduced through heuristics. If this option is disabled, the vibration rate is limited to 100 vibrations per second, excluding vibrations with an amplitude value of 0 (which is considered as the "not vibrating" state). This rate was determined to be safe through testing by [Morph](https://github.com/Morph1984) and [Ren](https://github.com/renA21).
 
 {{< imgs
 	"./configure_vibration.png| Vibration Configuration Window"