NTSC/JP Xenoblade 60fps and other mods

One More Try · (This post was last modified: 09-07-2017, 03:33 PM by One More Try.)

I made one more Burst B code if you want to tell me your thoughts. It's three frames (values 200, 205, 210 if you try the BPs I posted before) centered correctly - one before, one perfectly aligned, one after. Since it's only 3 frames it's a bit more difficult.

$burst checker change
04667870 43480000
C2181264 00000002
EC0010FA EC00182A
60000000 00000000

JershJopstin · (This post was last modified: 09-08-2017, 02:24 AM by JershJopstin.)

That info was what I needed, thank you. I've actually been working with off that info yesterday, but forgot to respond. Some updates:

-A refined version of the initial code I wrote seems to be getting the smoothest results of anything I've tried. (I accidentally overwrote the comments at some point, sorry)

Code update: (Show Spoiler)

-It's mostly the same as what I was trying to do before, but actually implemented correctly. The biggest change is that I implemented the conditional difference flip I mentioned earlier.
-There's still a lot of jumps, but it's significantly better than the default calculation
-I'm not actually sure if I'm handling angles bigger than 180 properly, as I haven't found an angle bigger than 180.

I've also tried another approach. It adds or subtracts 180 from each angle until they're within [0, 180]; effectively the remainder of dividing by 180. Then it proceeds with restricting to [0,90] similarly to before. I'm including it here because while it has jumps in places my initial approach didn't, it's also smooth in areas the other isn't; may be useful for testing.

alternate calculation: (Show Spoiler)

They're both a little rough in terms of efficiency, but I'm more concerned about getting either of them working first. I don't edit f28 because I couldn't remember if it needs to hold its original value after the calculation or not.

I can test how the other burst b feels soon. /edit: That feels just like the regular 30fps timing to me. I'd definitely use that over the first one.

One More Try · (This post was last modified: 09-07-2017, 03:02 PM by One More Try.)

Thanks for testing!

To find angles bigger than 180, just breakpoint the instruction (click left of it) that modifies angles bigger than 180. It should stop when it executes.

I didn't mention it before, but if you haven't realized: Codewrite labels jumps correctly for you. So if you put in loc_0x05, but it's really loc_0x20 it'll change it. The loc_0x00 are just markers. You can convert the code then reverse convert to check it.

f28 can be edited

And yeah, I have ways to optimize things if something works. paired singles and fsel. It's hard to follow without comments though. I could comment it myself I guess.

I noticed Monster Hunter Tri uses the same function that these values feed into - the one to get sin from a lookup table, etc.

JershJopstin · (This post was last modified: 09-07-2017, 03:34 PM by JershJopstin.)

Regarding checking >180: I feel like I should've thought of that myself, thanks. /edit: Dang, there are values above 360. That could break things, I think... /edit2: It should only break the algorithm if above 540

I've noticed the auto-labeling, yeah. It's quite helpful.

I'll comment it again soon when I have the time, don't worry about it.

One More Try · (This post was last modified: 09-07-2017, 04:48 PM by One More Try.)

hmmm the sin lookup function caps at 360. I'll see if it tries to do anything with greater values.

It multiplies the angle by 0.71111 which makes 360 -> 256 = 100 in hex. 359 becomes FF. It chops off anything greater than two digits, such that 360, 720, etc overflows into the third digit and is ignored and the first two digits properly get the significant part of the angle. It also finds cos, not just sin. I was wrong, it can pull negatives out of the sin/cos lookup. (I think I said it couldn't)

/edit If the starting value is negative we should just add 360 to it, instead of abs. A bit annoying for values over 360.

/edit2 Sorry I should have done more work on the function that uses the values. The cos of 4 and 176 is different by a negative. So those two values are technically different.
Do I need to go through all the math it does with the sin and cos then?

JershJopstin · (This post was last modified: 09-07-2017, 05:02 PM by JershJopstin.)

My first approach treats negative sin values separately. Curiously, this doesn't always seem like the correct thing to do, though (I've found one particular case where it'd work correctly if I abs the angle. It breaks most other cases, though, so there's got to be another reason that works in that instance).

I don't think you need to go through what it's doing with sin and cos; we should be able to find an intermediate angle that works with both regardless. It may help us figure out what we need to do to find the intermediate angle, though (if that's what you meant, go for it).

Tomorrow I'll try to compile of list of cases with various input ranges, and record what the correct differences are. I keep running into cases that I can't seem to fix without breaking everything else; I feel like I'm just looking at smaller snapshots of a bigger picture. Looking at multiple cases at once should help.

One More Try · (This post was last modified: 09-07-2017, 07:16 PM by One More Try.)

Your refined code has an f31 in it. Maybe you weren't done converting it to the one code method?

It looks like if you have >180 you might want to subtract 360 from it, which wouldn't change the angle at all, it'd just convert it to a negative definition. It'd work for differences of -60 vs 300. If you do an if negative -> add 360 before that, you'd squeeze it between -180 and 180 without changing the angle at all.

JershJopstin · (This post was last modified: 09-08-2017, 02:47 AM by JershJopstin.)

Whoops. I believe I added that instruction after switching to f28, must've forgotten. Unfortunately, fixing it didn't change very much.

Alright, I definitely should add comments soon, as what you described is exactly what I'm doing in the first half of my loop. /edit: done. /edit2: my counter logic is in fact broken. if you're wondering why something about it is the way it is, it's probably because it's wrong.

JershJopstin · (This post was last modified: 09-08-2017, 05:26 AM by JershJopstin.)

Does it always lookup both sin and cos?

One More Try · (This post was last modified: 09-08-2017, 12:01 PM by One More Try.)

Yeah, then it multiplies them together in various ways between the three values.

I think rather than automatic calcs after setting it between -180, 180 we need to compare the difference and make adjustments based on it. Like if the difference is greater than 90, but it's 88 vs -88, then just neg one. Or just check if the negative of one side makes the difference smaller -- within limits 2, -2 wouldn't want to trigger it probably...

I saw a value over 3000 Sad

I'll need that remainder code.

It'll sometimes skip over our difference code entirely and intentionally load a certain value. Not sure if that's the source of any bugs. My difference comparison code runs rather well with mostly camera glitches.

-47 and -132. 62 and -113. Seem to throw errors if not aligned.