API tools faq
paste
imbued

camera angle while walking incomplete info

imbued
Sep 28th, 2026 (edited)
36
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 6.85 KB | None | 0 0
raw download clone embed print report
  1. When you have a facing angle and press and hold target, your camera angle sometimes changes to something different from your facing angle, usually it goes up to the next 0x10 angle bin and the last digit is either a 0 or a 1. When you release target, your camera angle will often remain at this value, but in some cases it will actually be different. I will explain more below.
  2.  
  3. If you hold target and walk forward, your angle will snap to your camera angle, then when you stop walking it'll snap back to the original angle, e.g. 0xFC00 angle targeted has 0xFC10 camera angle, walking while targeted gives an angle of 0xFC10 (and, importantly, thus a movement angle of 0xFC10). For this specific angle, releasing target while standing still happens to keep your camera angle at 0xFC10 and your angle will be 0xFC00 again. Now suppose you walk forward *untargeted*, the first frame of holding up on the control stick you will have a linear velocity of 0 but your angle will snap to the camera angle, so both angle and camera angle will be 0xFC10. This will remain the case for the speed-2 and speed-4 frames of deku walking, but on the first speed-6 frame, your angle will still be 0xFC10 but your camera angle will update to 0xFC20. On the second speed-6 frame, angle will snap to camera and the camera does not update (in this case, there are counterexamples that I discuss below) so both of them at 0xFC20. Then on the third speed-6 frame, camera angle updates to 0xFC30 and angle (and thus movement angle) stays at 0xFC20. On the fourth speed-6 frame, both angle and camera angle are 0xFC30.
  4.  
  5. To summarize how walking while untargeted works (`angle`=facing angle, `cam`=camera angle, `v`=linear velocity):
  6. frame 0: angle=0xFC00, cam=0xFC10, v=0 -- start holding up on the control stick on this frame (while untargeted!)
  7. frame 1: angle=0xFC10, cam=0xFC10, v=0 -- (angle snaps to camera before you move at all)
  8. frame 2: angle=0xFC10, cam=0xFC10, v=2 -- (velocity updates from 0 to 2, camera stays the same)
  9. frame 3: angle=0xFC10, cam=0xFC10, v=4 -- (velocity updates from 2 to 4, camera stays the same)
  10. frame 4: angle=0xFC10, cam=0xFC20, v=6 -- (velocity updates from 4 to 6, camera updates by 0x10)
  11. frame 5: angle=0xFC20, cam=0xFC20, v=6 -- (angle snaps to camera)
  12. frame 6: angle=0xFC20, cam=0xFC30, v=6 -- (camera updates)
  13. frame 7: angle=0xFC30, cam=0xFC30, v=6 -- (angle snaps to camera)
  14. frame 8: angle=0xFC30, cam=0xFC40, v=6 -- (camera updates)
  15. frame 9: angle=0xFC40, cam=0xFC40, v=6 -- (angle snaps to camera)
  16. etc. (camera updates every 2 frames once you have velocity of 6)
  17.  
  18. So in this example, we see that the camera angle is updating every 2 frames. Most angles in the range of interest (I'll define this range of interest later) will have updates every 2 frames of untargeted walking forward, but there are some angles throughout which are only active for 1 frame!
  19.  
  20. For example:
  21. 0xFEE1 lasts for 2 frames
  22. 0xFEF1 last for 2 frames
  23. 0xFF01 lasts for only 1 frame!
  24. 0xFF11 lasts for 2 frames
  25. 0xFF21 lasts for 2 frames
  26. 0xFF31 lasts for 2 frames
  27. 0xFF41 lasts for only 1 frame!
  28. 0xFF51 lasts for 2 frames
  29. 0xFF61 lasts for 2 frames
  30. 0xFF71 lasts for only 1 frame!
  31. 0xFF81 lasts for only 1 frame!
  32. 0xFF91 lasts for 2 frames
  33. 0xFFA1 lasts for only 1 frame!
  34.  
  35. So what happens if we try to walk untargeted starting from a camera angle that only lasts for 1 frame? We can try to test this by getting an angle of 0xFEF1, then holding target gives us a camera angle of 0xFF01 which is one of the angles that only lasts for 1 frame. Great, so let's untarget and try to walk forward. Well, it doesn't quite work like that. Once you're untargeted, your camera angle will actually no longer be 0xFF01, but instead it will be 0xFF11 which is an angle that lasts for 2 frames.
  36.  
  37. Okay, so let's try starting from 0xFF61 which lasts for 2 frames but is followed by 0xFF71 and 0xFF81 which both only last for 1 frame. If you have angle 0xFF61 and hold target, your camera angle will be 0xFF71 while holding target, but once you release target your camera angle jumps all the way up to 0xFF91, so the camera angles that last for 1 frame get skipped entirely!
  38.  
  39. Just to really emphasize this, let's look at a case where there are even more consecutive "1-framers".
  40.  
  41. 0xFF91 lasts for 2 frames
  42. 0xFFA1 lasts for only 1 frame!
  43. 0xFFB1 lasts for only 1 frame!
  44. 0xFFC1 lasts for only 1 frame!
  45. 0xFFD1 lasts for only 1 frame!
  46. 0xFFE1 lasts for only 1 frame!
  47. 0xFFF1 lasts for only 1 frame!
  48. 0x0000 lasts forever (no matter how much you walk forward, your angle and camera angle will stay at 0x0000... assuming you don't run into a slanted wall or something, obviously)
  49.  
  50. If my angle is 0xFF91 and I hold target, my camera will be 0xFFA1. However, once I release target, my camera will be 0x0000 because there are only 1-framers between 0xFF91 and 0x0000, so they all get skipped!
  51.  
  52. Now for the "range of interest" I mentioned above. Notice how the angles I looked at above are really close to a cardinal direction (i.e., 0x0000). Which side of the cardinal they're on matters a lot though. For example, 0x0010, 0x0020, 0x0030, and more are all absorbing states (last forever).
  53.  
  54. TODO TODO TODO TODO TODO
  55.  
  56.  
  57. Other cases:
  58. There are also angles where the targeted camera angle goes up to the next 0x10 bin, but if you instead did not target to begin with it is an absorbing state. For example, get angle 0xFB40, then target and you will have a camera angle of 0xFB50. Walk forward untargeted and you will stay at 0xFB50 forever. But if you hold target with angle 0xFB50, the camera angle will increment up to 0xFB60 and remain at 0xFB60 even if you untarget. Because of situations like this, simply targeting and observing cam angle, then untargeting and observing cam angle is insufficient to determine the full behavior of the angle (it could either be an absorbing state or it could be a 2-framer)
  59.  
  60.  
  61. A side note about deku spinning and the speed threshold (discussed above to be 6, but technically it is lower) for the camera to update while moving forward untargeted: As far as I can tell, deku walking and deku spinning forward appear to behave the same way in terms of how the camera/movement angles update with a linear velocity of 6 or higher seeming to be the magic number to for the camera to have the chance to update. Note: I got a speed of 5.65946 with a deku spin and this seemed to be sufficient for the camera to update, but the next frame I had speed 5.27027 which appeared to be insufficient, so a speed of 6 is NOT the minimal value. In fact, it must be something other than speed entirely: partially holding up on the control stick gives deku a speed of e.g. 3.20064 which ends up being sufficient to update the camera, yet in other cases with regular walking and deku spinning it seems whenever the speed is below ~5.5 the camera never updates and when above it seems to always update (or be capable of updating, at least, since some are absorbing states which never update).
  62.  
Advertisement
Add Comment
Please, Sign In to add comment
Public Pastes
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!