Dolphin, the GameCube and Wii emulator - Forums

(09-10-2017, 11:28 AM)One More Try Wrote: [ -> ]Thanks, I tend not to use the intro as a benchmark because it has more lag than normal.  Could you see if a normal fight after that, with the Monado, is much worse?  I can probably look into any lag issues that are past the intro.

Also, what is the last code you're referring to?  Is it a final alpha code or a code in the first post?

The issue happens just by standing still without doing anything, it randomly stutters every 10 to 15 seconds for less than a second and then it goes back to 60 fps, after another 10 to 15 seconds it stutters and then goes back to 60 fps, etc... The Monado fights in the beginning runs fine at 60 fps but it still stutters every 10 to 15 seconds. The same issue happens in the beginning when using Shulk, hopefully this can be resolved.

I reverted back to the older code which is the "Beta 60fps code", that's the first code you provided in the first page on this thread.

(09-10-2017, 12:50 PM)JershJopstin: Wrote: [ -> ]In addition to One More Try's questions, what do you mean by stutter? Dropping down below 60 but still running (and still staying above 30), or hard pauses that last half a second or so? If it's the latter, are you running a version of dolphin that's newer than 5.0-4575?

By stutter I mean the hard pauses that last half a second, the game runs fine at 60 fps but suddenly it stutters (hard pauses) for less than a second for no reason, this issue doesn't happen with the first code available in the beginning of this thread.

The Dolphin version I'm using is: 5.0-5075

(09-10-2017, 02:02 PM)Resus Wrote: [ -> ]By stutter I mean the hard pauses that last half a second, the game runs fine at 60 fps but suddenly it stutters (hard pauses) for less than a second for no reason, this issue doesn't happen with the first code available in the beginning of this thread.

The Dolphin version I'm using is: 5.0-5075

I had this issue as well, try downloading a version of Dolphin that's older than 5.0-4575 and copy codehandler.bin from \Dolphin-x64\Sys from the old one to the new one. That said, I didn't realize 'Beta 60fps code' in particular didn't have the issue. I may look into which specific code is causing it when I have time.

One More Try: I'm getting 30fps and half speed main menu/file select again in Final 3.

(09-10-2017, 02:52 PM)JershJopstin Wrote: [ -> ]I had this issue as well, try downloading a version of Dolphin that's older than 5.0-4575 and copy codehandler.bin from \Dolphin-x64\Sys from the old one to the new one. That said, I didn't realize 'Beta 60fps code' in particular didn't have the issue. I may look into which specific code is causing it when I have time.

One More Try: I'm getting 30fps and half speed main menu/file select again in Final 3.

Thanks mate!, that indeed fixed the issue. I replaced codehandler.bin from 5.0-4550 to the Dolphin version I'm using and everything is running fine now.

Keep up the awesome work dudes!

Glad there isn't an issue.

@Jersh Check your gecko codes for any comments containing stuff other than Letters, Numbers, and // I think it's that problem again. Also make sure you're not running the Movie code.

I didn't know you were going to thoroughly look into the sine code, I could have given you a few tips. If you breakpoint 803e1a90 and record f31, f30, f29 then skip forward to a breakpoint at 8040d680 you will see f0, f1, f2 have the sine and cosine values calculated out. I forget the order, but at the first breakpoint you can manually enter angles to see what the output will be. If there's no issue with the values at the second BP, it probably doesn't matter what happens between those two points.

My best code takes the absolute values (0 to 180) and rotates frame2's value by 180 (180 - val) whenever one value is below 90 and one is above, but there are some sign issues.

I had to learn a few new tricks, but I made a code that differences the output after the sine is taken and calculations are done. It's laggy as hell for me and the original angles get saved and sometimes used after this code, but I'm not sure that causes any problems. The bugs may be only from skipping differencing code.

Don't use the loader code.

Oh and some bad camera MBPs 92727704 to 9272770c, 92727728 to 9272772c during early in the intro.

Hmm. I was only running the final 3 code, and I can't find non-standard characters, but making a new .ini with just the final 3 code fixed the issue. I was going to report that movies were still choppy at the end, but the new .ini seems to have fixed that as well.

It seems movies last a couple frames too long, though. For example, after the movie showing the Bionis Leg for the first time, the camera quickly cut to Shulk before queuing the next cutscene. I'll double check to make sure this doesn't happen normally. Edit: it doesn't.

Nevermind, found the issue. Fixed the character showing up for a moment between scene switches. Updated previous code post.

The choppy movies was a code bug.

/edit Finished updating the JP code. I had a weird bug where the Burst Affinity B prompts never unlocked, never had the tutorial message, and never appeared. Had to replay the game from the beginning. No idea what caused it, maybe I was using an old buggy code when I did that part the first time? I'll probably have to include a warning now, but I tested it and didn't see any more issues with the current code.

I'll get back to testing the beta code in my free time soon. It would probably be good to have something bug-free (as far as we can tell, anyway) available while I'm obsessively trying to figure something out for 60fps movies (it's okay, I actually enjoy the involved math).

One last thing on it before I put it on the back burner to testing the beta code for a few days - while looking through the sine/cosine values, it seemed very odd to me that 4 and -176 would produce such similar onscreen results, despite having very far apart cosine values. Going through the calculations, all the sine and cosine values are multiplied together - except for the sine of f30, for whatever reason. Curiously, I checked the angles for f30 and f29 on that same frame, and sure enough, f30 was flipped in a way that produced a flipped cosine value, and f29 was flipped to produce both a flipped sine and flipped cosine value; effectively giving the same results. I checked another frame where f31 flipped, and f30 and f29 flipped as expected again. Figuring there was a chance this was always the case, I threw together code that checks f31 for a flip (defining a flip as movement >90 degrees), and either flipped all three angles or none accordingly, but unfortunately the result was less smooth than my sine-aligned code, let alone the improvements you've made since. There could be several reasons for this, but I think the most likely perpetrator is how I'm detecting a flip (I'm running into a similar problem with how you decide when to rotate around 180- I do have an idea, though). However, as the light sword actually doesn't seem to have any flickering issues with that particular code, I'll need to find a different model to work with.

Alternatively, I could be entirely on the wrong track and angles can flip independently of each other, but given that they're being multiplied together, I don't understand how that would work.

Yeah, that's what I was thinking, but I didn't thoroughly look into it. Got a bit to complicated to follow. Do you think arcsin(abs(sin(Frame2)) - abs(sin(frame1))) is correct?

Don't forget that -26 vs 26 is also a rotation like 176 vs 4. If you want the signs to lineup. Like a check for if one is negative and a check if they flip around 90, 180, etc would be needed. I think checking 180 would be more responsible?

I got a shortened code to extract the sign of f0 and f25 into f21 and f22.
fdivs f17, f18, f18 ;1
fneg 19, 17 ;-1
fsel f21, f0, f17, f19 ;choose 1 if f0 = zero or above, else choose -1
fsel f22, f25, f17, f19

For rotations, maybe you could take the Abs and divide by 90, then floor the result and compare for both frames to see if anything rotated.
ps_merge00 f22, f22, f21
psq_st f22, 12(r2), 0, r3
psq_l f22, 12 (r2), 0, r3
ps_merge11 f21, f22, f22
I think that will floor f22 and f21 and place it back in f22/f21. Codewrite will put in junk code starting with a 00000008, which you have to delete then you have to change the top right-most number to the correct number of lines (subtract 3 or 4).

Anyways, if you're going to bug hunt Xenoblade, I'll play the JP version myself to check it.

(09-11-2017, 05:45 PM)One More Try Wrote: [ -> ]Yeah, that's what I was thinking, but I didn't thoroughly look into it. Got a bit to complicated to follow. Do you think arcsin(abs(sin(Frame2)) - abs(sin(frame1))) is correct?

No, I don't. While this works for -176 and 4, it shouldn't for, say, -4 and 4; based on what I'm seeing in the calculations, 4 flips to -176 as that inverts both sine and cosine. Because -4 has only a flipped sine compared to 4, it should just be 8 degrees away.

Quote:Don't forget that -26 vs 26 is also a rotation like 176 vs 4. If you want the signs to lineup. Like a check for if one is negative and a check if they flip around 90, 180, etc would be needed. I think checking 180 would be more responsible?

Do you have an example of a case like this? As far as I can tell, 26 should flip to -156 if it's f31 or f29, and 156 if it's f30. I don't recall seeing a case where an angle should just be abs'd. If there is one, I'd like to see it.

Quote:I got a shortened code to extract the sign of f0 and f25 into f21 and f22.
fdivs f17, f18, f18 ;1
fneg 19, 17 ;-1
fsel f21, f0, f17, f19 ;choose 1 if f0 = zero or above, else choose -1
fsel f22, f25, f17, f19

This helps, thanks.

Quote:For rotations, maybe you could take the Abs and divide by 90, then floor the result and compare for both frames to see if anything rotated.
ps_merge00 f22, f22, f21
psq_st f22, 12(r2), 0, r3
psq_l f22, 12 (r2), 0, r3
ps_merge11 f21, f22, f22
I think that will floor f22 and f21 and place it back in f22/f21. Codewrite will put in junk code starting with a 00000008, which you have to delete then you have to change the top right-most number to the correct number of lines (subtract 3 or 4).

While I don't like that formula for reasons listed above, I did see similar instructions to floor a number inside the sin/cosine calcs so that's probably the correct way to do it. I may use that to initially constrict the angles to a given range (probably [-180,180]).

Quote:Anyways, if you're going to bug hunt Xenoblade, I'll play the JP version myself to check it.

I've started a playthrough recently that I'm playing exclusively with the 60fps code. It's how I noticed more obscure things like the b prompts and the smiley animations.

Was playing with the Final Alpha 3 code and it seems to work great! only minor bug I noticed is in the opening scene where Mumkhar runs off and gets a bunch of lasers pointed at him only one laser appears when using the 60 fps code versus the dozens that normally appear.