Emulator

Not Sonic Advance, Sonic Heroes :P

Please respond if this issue is still valid, or it will be closed.

This is no longer a problem for me (didn't know this issue was for Heroes, wtf @ Advance being there).

I say, fixed.

Hmm, it's still a problem for me as of r6546, so it's not entirely fixed for everyone...
I'm having this issue almost all the time (in-game as long as the game isn't paused, and in a few menus), and that makes the (PAL) game mostly unplayable for me. I think I tried disabling Dual Code and even using the Interpreter (I'll have to double-check that), without success...

What seems to happen to me for some reason is that the game sometimes thinks that all buttons and axises are zeroed out (about every 2 to 6 frames), and that makes some obstacles hard or even impassable (such as when using Big's umbrella to fly up using wind for example).
I'm not sure where the issue actually comes from, but I checked that the CSIDevice_GCController::GetData() function isn't the cause. It happens somewhere in a few frames...

Indeed, this issue occurs even when the (PAL) game is started with the Interpreter and in Single Core mode.

I wonder what differences (game-region-wise or system-wise for example) could give different results...

Issue 1330 has been merged into this issue.

Please test if this issue has been fixed in r6552.

I tried r6552 with the "Dual Core" and "Idle Skipping" options disabled. The auto-fire problem isn't fixed yet.

Issue 1542 has been merged into this issue.

I meant in comment 6 that the Pad::GetStatus() function call in GetData() (the former, not the latter) isn't causing the problem, as I put a breakpoint right below it (using VS2008's debugger) and noticed that the resulting struct is unaffected/constant (the A button bit remains set when the problem occurs for example).

Actually, I can confirm that the CSIDevice_GCController::GetData() isn't the direct cause for this problem. I set a breakpoint at the final line of that function (244: "return true;") and I observed the _Low and _Hi values, which appear to be unaffected by the "special button combo" code, although the problem still persists.
This remains the same even when I comment the "_Hi |= 0x00800000" line, or when I add a "return true" before the "special button combo" part of the code.

Now here's something interesting that reinforces the previous claim:

• the "button states" at [8040F030] (P1), [8040F038] (P2), [8040F040] (P3) and [8040F048] (P4) show no symptoms, as these are (possibly) the 64-bit values that come from the GetData() function;
• the "button states" (which are reorganized in a sort of struct) at [8029C1FA], [8029C23E], [8029C3C2], ..., [8029C7B4] appear to be zeroed out at times, as I explained in my first post here.

Not sure where to continue from now on. Perhaps memory breakpoints at [8040F030] and [8029C1FA] along with some code debugging will help?

Issue 237 has been merged into this issue.

Can anyone confirm that it only happens in PAL? I've just tried NTSC-U version of the game and didn't notice anything wrong.

The effect is continuous, or only happens at certain points?

(...if that's a good idea, of course.)

GameIssue didn't really make sense. All the bugs being reported should come down to a concrete emulation bug, having a classification for GameIssue just means that the root cause is unknown. It should by Type-Defect and status should reflect how much we know/are doing about the issue.

That's what I think, at least :P

On topic: I guess I'll check out the PAL version.

yea so the 8bytes from 8040F030 look fine like you said. You think 8029c7b4 is the stick's value in that struct?

afaict, the problem has something to do with the func at 801df624 (recognized at SPEC2_MakeStatus by symbol db). It seems like it's the callback used by PADRead each time. Unfortunately we can't just patch it out :p

ps. in this case, spec0/spec2 is referring to the versions of the pad hardware.

also, patching the callback to spec0's handler results in rather funny behavior ;p

Still exists in PAL version in Dolphin 3.0 638. Any updates on getting this solved?

This bug apparently affects all the multiplayer modes for some reason.

Still happens with 4.0-8445, can confirm it doesn't happen on NTSC-U or NTSC-J version only on PAL. If you execute a throw move and then push in the direction you want to move as soon as you land you will move at normal speed, if you stop then try to move you'll move at the pace people have described.

Happens in 3.0 but not as frequently as latest build, character can run at full speed from standing most times.

Issue is shown here https://youtu.be/oyVr9zBEX7s

For some reason Youtube deleted the video as a duplicate? https://youtu.be/AaD1N5OBjt8

Fixed in PR3457 -> https://github.com/dolphin-emu/dolphin/pull/3457