- Joined
- Aug 22, 2025
- Messages
- 58
- Reaction score
- 34
- Trophies
- 0
- Website
- derivativeoflog7.github.io
- XP
- 293
- Country
I made some patches to tweak the 3rd person camera on The Legend of Zelda: the Wind Waker HD, for both Cemu and Aroma, and for all three regions.
The currently available patches are:
Download, instructions and source code are available here: https://github.com/derivativeoflog7/WWHD_3pCameraTweaks
The patches are made specifically to only affect the 3rd person camera controls; they will not affect the 1st person camera controls, playing music with the wind waker, etc.
I have played through the whole game (European release) on console with both patches active, and have not encountered any issues or unexpected side effects.
Credits
The Aroma plugin uses code from Inkay (specifically, for finding the address and patching the instruction) and from the WUPS example plugin (settings handling, logging, makefile).
Many thanks to the Cemu team, as the debugging tools were key for me to figure this out; Maschell and techmuse for pointing me in the right direction for creating the plugin; Maschell again for helping me figure out how to use libfunctionpatcher for this; and ComradeWave for helping me out.
How the patches work
Additionally, since the two patches affect two different sections of the game's code, they can coexist without any issue or extra complexity.
The currently available patches are:
- Invert Y axis (everywhere)
- Consistent Y axis: prevents the game from inverting the Y axis in certain locations
Download, instructions and source code are available here: https://github.com/derivativeoflog7/WWHD_3pCameraTweaks
The patches are made specifically to only affect the 3rd person camera controls; they will not affect the 1st person camera controls, playing music with the wind waker, etc.
I have played through the whole game (European release) on console with both patches active, and have not encountered any issues or unexpected side effects.
Credits
The Aroma plugin uses code from Inkay (specifically, for finding the address and patching the instruction) and from the WUPS example plugin (settings handling, logging, makefile).
Many thanks to the Cemu team, as the debugging tools were key for me to figure this out; Maschell and techmuse for pointing me in the right direction for creating the plugin; Maschell again for helping me figure out how to use libfunctionpatcher for this; and ComradeWave for helping me out.
How the patches work
The patch replaces a single
with a
at a point where the code copies the Y position of the right stick into a data structure that's soon after used to calculate how to move the camera, thus negating the value.
Code:
fmr f29, f1
Code:
fneg f29, f1This one is a bit longer to explain.
The first thing to know is that, for some reason I can't fathom, someone thought it was a good idea to associate moving the right stick up to zooming in, and vice versa, rather than associating them to the direction the camera moves.
This is the root cause of the camera Y axis inverting sometimes, as in most locations the camera moves down when you zoom in, but in some it instead moves up.
Each location has programmed in a target angle for when the camera zooms out (which acts as the max/min angle), and one for when the camera zooms in, with the angle being 0 when the camera is horizontally parallel to Link, and positive when the camera moves above him.
When the camera zooms in, if the zoom in target angle is less than the zoom out target angle, it moves down, otherwise it moves up (and vice versa when it zooms out).
The patch puts a jump to custom code at a point inside the function that calculates camera movement where it has already loaded/set all parameters, and is about to start performing calculations on them.
The custom code compares the zoom target angles, and if the zoom out angle is smaller than the zoom in angle, it negates the right stick Y position reading; this causes the direction of the camera to invert in only one of the two previously mentioned cases, thus making the axis consistent.
The first thing to know is that, for some reason I can't fathom, someone thought it was a good idea to associate moving the right stick up to zooming in, and vice versa, rather than associating them to the direction the camera moves.
This is the root cause of the camera Y axis inverting sometimes, as in most locations the camera moves down when you zoom in, but in some it instead moves up.
Each location has programmed in a target angle for when the camera zooms out (which acts as the max/min angle), and one for when the camera zooms in, with the angle being 0 when the camera is horizontally parallel to Link, and positive when the camera moves above him.
When the camera zooms in, if the zoom in target angle is less than the zoom out target angle, it moves down, otherwise it moves up (and vice versa when it zooms out).
The patch puts a jump to custom code at a point inside the function that calculates camera movement where it has already loaded/set all parameters, and is about to start performing calculations on them.
The custom code compares the zoom target angles, and if the zoom out angle is smaller than the zoom in angle, it negates the right stick Y position reading; this causes the direction of the camera to invert in only one of the two previously mentioned cases, thus making the axis consistent.
Last edited by derivativeoflog7,
