Alright, I just got home to work on this. A few questions: /edit: figured them both out, was looking at it wrong.
NTSC/JP Xenoblade 60fps and other mods
|
09-06-2017, 08:53 AM
Could you try this? It works over 4 frames. Hoping it feels ok. Big thanks for spotting it.
$Burst B Prompt Fix C21808FC 00000003 EC431824 EC42102A EC631024 C05F0098 60000000 00000000 09-06-2017, 09:02 AM
(This post was last modified: 09-06-2017, 09:32 AM by JershJopstin.)
Feels too generous. Give me a minute to frame test and see what's up.
Edit: Alright, perfect's didn't require you to be quite as perfect as I remember. Couple that with the extra frame of intermediate animation making it look like you can press it later and the general responsiveness of 60fps in general, and I got confused. The timing is correct as far as I can tell, good work! Edit 2: I'm stuck on actually running my code in dev mode. I just... can't seem to figure out how to do it lol. 09-06-2017, 09:40 AM
(This post was last modified: 09-06-2017, 10:47 AM by One More Try.)
30fps. It counts by 5. 100, 105 = good. The cutoff is 107.5 (which is never hits directly).
60fps. It counts by 2.5. 100, 102.6, 105. 107.5 are good. Maybe it should be moved back/out by 1 frame? If you want to practice with the debugger. 80181268 has the comparison and 80180910 updates the value every frame. So you'd just breakpoint (BP) those and watch the f1 and f2 register. 09-06-2017, 10:00 AM
Maybe it should be backed a frame. Hard to tell. I suppose it can't hurt to try.
Slowly learning the debugger, things are starting to click. 09-06-2017, 12:33 PM
(This post was last modified: 09-06-2017, 12:35 PM by One More Try.)
I missed your comment about running your code. You use Codewrite to turn it into a gecko code with address 803e1954. Then just put it in as gecko and enable it. Like I said before, there are 3 values you have to apply the code to, and right now that requires copying it three times to three addresses... I'm going to write something that can avoid that. You can then breakpoint 803e1954 to see the code or put that in the left search box of the code tab when the game is paused, if it worked there will be a branch there and you can right click the branch and follow it.
09-06-2017, 01:13 PM
Forgot to say I finally managed to grasp what was going on in terms of code flow, but thanks for explaining anyway. I haven't been that knee-deep in something unfamiliar in a long time, feels good to learn something.
09-06-2017, 02:43 PM
(This post was last modified: 09-06-2017, 02:45 PM by One More Try.)
Great. PowerPC is rather fun to poke around in.
I made a loader for the code, just make it a separate gecko code. Movie code loader: -Change f23 to f24. Don't need to change the f24's or loop at all. Avoid using f23. -Change f31 to f28. f28 will now automatically carry any of the three values into the code, they will update to f31, f30, f29 after leaving the code. -End the code with: fcmpo cr0, f27, f2 beq- loc_0x7C blr loc_0x7C: fmr f27, f18 -Don't use f27 --Also I don't think you want that "sign tracking" line. 09-06-2017, 03:51 PM
(This post was last modified: 09-06-2017, 04:07 PM by JershJopstin.)
-The ending was made much more hastily than I realized. I've made it loop properly since, but if avoiding f23 is necessary, than I'll look at it again.
-The sign tracking (probably should've called it sign update) line is necessary, but should've definitely been immediately after the absolute value update. Not entirely sure why I put it where I did, since it doesn't always trigger if it needs to (and that's not a particularly natural place to put it anyway). -The difference should be inverted at the end - well, I could say that, and it'd fix a problem angles from [-90,90] are having right now, but the problem is hitting the 180-f0 operation potentially inverts the difference - but not always. It will invert the difference if both angles hit it, but if only one hits it, it'll invert the difference only if the angle being operated on's absolute difference from 90 is greater than the other angle's. My biggest frustration right now, however, is how difficult it is for me to determine what the values I'm seeing are actually doing to the models. With how many times the algorithm actually occurs each frame, I can't really tell what corresponds to what. Even if I fix all the bugs with what I posted, I'm not sure the approach is even correct in the first place. The thing really nagging me about this is that, by aligning by sine, 89 = 91 - and that just doesn't sound right to me. However, without a real visual confirmation, I can't be sure. Is the point of the loader to make it so I only need one code instead of copy-pasting? If so, should I insert my code at at 803E1954, or one of the other 2? 09-06-2017, 05:09 PM
(This post was last modified: 09-07-2017, 12:28 AM by One More Try.)
Yeah, it removes copy pasting. Just put your code in at 954 and leave the other places alone.
You can poke values by directly editing f31, f30, f29 after they are completely set (or before to test code). r4+r3 on the left registers track what the value relates to. One particular buggy value is read from 9270c760 and 64. So you can set a MBP break point, read, range from 9270c760 to 9270c764. And it'll pause during the first few sword swings. You'll see a 4 and -176 get differenced. You can go view -> memory to look at the value near there, paste it in the top search box. You can probably follow one model part by just MBPing a range from r4 to like r4+400? (look at r3 for how far it counts). |
« Next Oldest | Next Newest »
|
Users browsing this thread: 1 Guest(s)