Dolphin, the GameCube and Wii emulator - Forums

Tweaking those settings does nothing on my end. As a sanity check, the only code I have running is the one you labeled 'Final Beta'. Perhaps I'm missing something, or maybe you have something different in the code you're running on your end by accident?

Something else I've noticed: I get a lot of random stuttering with this patch on. I'm running on hybrid mode, so it's not shader compliation, and running the game without the patch at 200% speed (without changing any other settings) doesn't produce any such stutter. Any ideas? I'm running a 3930K with a 290X, if you're curious.

Also, with the bit of math you posted earlier, shouldn't the domain be -360 to 360, while the range is -180 to 180? The way I'm understanding what you wrote, I'm having trouble figuring out how you would get an output bigger than 180. If you think the oddness you described is due to a lack of accuracy with your calculation, I'm willing to help you pursue this further.

I also tried various combinations of VSync and EFB2TEX, but to no avail. For what it's worth, my usual settings are VSync on and EFB to Texture. Just to make sure we're on the same page, I recorded myself going through the main menu with FRAPS, which you can see here: https://www.youtube.com/watch?v=bmOkbAOyCBc

@Jersh Yeah, I recopied the code I posted and tried it, but no difference on my end.

Is the stuttering during anything in particular like battles? Cutscenes? No Cutscenes? Standing still on the world map doing nothing? Try deleting everything above End Optional and see if that makes a difference, since most of the new code is there.

I don't think I can arcsin in assembly. The accuracy comment isn't too important because of that. What I tried math-wise was to force everything between -90 and 90 by selectively subtracting 180 or 360. Then finding the absolute difference. Then adding or subtract half the difference to the first original value based on what moves it closer to the second value. Maintaining the sign of the original first value. My main problem ended up being some values still jumping from like 40 to 80, and I don't think the mid-point of that is correct. Plus it's difficult to figure out which values correspond to which visual glitches.

@Kura Movie -> Show Frame Counter. Is the splash screen also 30 fps?

Hmm... I'll still look for what's dropping my frame rate with EFB to Texture in case that's causing more weirdness.

there are probably sin routines in the game. you can try reciprocal of degrees than call the sin routine. fres is the reciporical instruction on powerpc

/edit Ah shit. I don't think commenting these gecko codes is officially supported, but I do it because it doesn't seem to cause bugs. This time I put periods in my comments and that is probably breaking things My bad! I'll update the original code. Remove the periods or re-copy the updated code and try again. I should also remove some of the conditionals from the gecko code and inject them into the game's code.

@Master The game does send the values into a sin lookup table, so I could just push both frame's values into the lookup table and then average them after the lookup. I just wasn't confident in that working. Plus it has a complicated way of dealing with the decimals. I think I would have to edit the main code to loop itself, rather than a gecko branch.

sidenote: The game has an interesting way to round down floats to the nearest whole. I don't know anything about qr's, but I guess that one does that?
psq_st p4, 8(r1), 0, qr3
psq_l p7, 8(r1), 0, qr3

https://www.youtube.com/watch?v=fCTRgrwgNmc

Alright, I recorded with FRAPS again, this time with both FPS display and frame counter on. I also went into the actual game this time to show that it does switch to 60FPS. Hopefully this helps.

Thanks, did you try with removing the periods from the code comments, or removing all the comments? I believe there is a meta-bug with the code that doesn't relate to how it modifies the game. It could also be due to checking the same address twice, which I'll change either way.

Alright, so, strangely, removing the periods didn't work... at first. However, I also noticed Dolphin wasn't saving which codes I was and wasn't applying from earlier (I had turned on infinite HP for easier testing of specific things, and it wouldn't turn off), so I deleted everything in the config, re-pasted, and tried again... and the opening menu is 60fps now. Not sure what happened there.

As for the stuttering (which, since I don't think I specified earlier, are momentary drops into single-digit fps), it can happen anytime; while it seems to occur more often while doing actions (such as battling, targeting an enemy, opening the menu, etc.), it still stutters even if I'm not touching anything. In fact, I've left just the map screen up while typing this, and it still stutters. Removing the optional code doesn't fix it (and I think I was still getting it in an earlier version of the code anyway, but hadn't pegged down the cause yet).

The math you posted seemed similar to a solution I was working out, though not quite right. Give me a moment to finish it and I'll report back (and, just for clarity's sake here, the range (not domain) should be -180 to 180, yeah? Based on my interpretation of the problem, 180 should be the correct answer for the difference between 90 and -90, and moving either angle in either direction should lessen the differnece).

Edit: Alright, so in modern pseudo-code, my solution would be this:
As far as I can tell, there's no jumps in this calculation. How easy this translates to assembly, I wouldn't know. This is definitely correct if I understood the premise correctly though.

/edit 2, erroneously had 'angle' in some areas where I should've typed 'angle1'.

Edit 3: Looked into the stuttering some more; it does not occur in the 5.0 stable release (the compilation stutter there is distinctly different). I suppose I'll try to find precisely which build the issue first showed up in. I confirmed it's still affecting the latest build, and I was using 5328 earlier, so if you're using something older than that feel free to update and test it yourself.

I think the period just corrupted something. Sorry.

I've randomly had issues with stuttering before, but Vulkan avoids that, and my CPU isn't that great, so I haven't been paying too much attention. I would probably approach it by looking at what part of the code causes it. You can strip it down to just an AR code (or gecko):
04819E68 00000001
04CA54C0 3F000000

If you want to try different builds give 615 (good) and 845 (bad) a shot. Not sure if it applies here.

I've attempted to remove two of the memory checks, which might improve performance. You can give that a try too:


As for the maths, I was thinking you didn't need to worry about negatives in the difference, so 90 and -90 is zero, because the sin is the same. If Frame 1 wants the sin of 90 and frame 2 wants the sin of 90 and a negative, I don't think the new middle frame wants the sin of 0. I just extract the sign at the beginning and re-add it at the very end. The main problem is it loading two values where the midpoint won't give a half step in animation, but a visual glitch instead. I tried to limit it to differences of 20, 30, etc, and it fixed some stuff, but never enough. The harder I looked at it, the more confused I got.

I tracked down cause of the stuttering (happens in every video backend, btw) to build 4575. The pull request in question is here. This actually modified the gecko code handler, and there are comments saying it causes what seems to be similar stuttering with widescreen hacks in other games. It seems just manually replacing the new code handler with the old one should work, but I'll try your newer code first.

Edit:That was kinda funny. In-game seemed to render fine in the quick minute I tested, but still stuttered. That single code you gave didn't stutter though.