Emulator Issues #960
Auto-fire / Control Stick Problem
What steps will reproduce the problem?
1. Running Sonic Heroes
What is the expected output? What do you see instead?
Sonic and other chars move very slowly because of control stick not moving
in direction I need. It's like half-pressing button.
What version of the product are you using? On what operating system?
Please provide any additional information below.
Other Gamecube games work properly.
#6 Updated by DimitriPilot3 about 8 years ago
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...
#13 Updated by DimitriPilot3 about 8 years ago
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, 8040F038, 8040F040 and 8040F048 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?
#17 Updated by DimitriPilot3 over 7 years ago
- Category set to controls
As I said, for me, using the plainly-dumped PAL game (MD5:45BF89BC3455C84C6EB54FBB41AD5287), this effect occurs in most (not all) situations: in-game so long as the game isn't paused, and occasionally (rarely) in a few menues (such as with the "loading successful, press A button to continue" message box?).
Using Dolphin (v3.0 this time) in single-core and CPU interpreter mode, with "Idle Skipping" disabled and with LLE audio emulation (on separate thread) has failed to make any difference in-game.
It'd be interesting to have many other tests using different regions of the game, just to know if that indeed is just a region-specific issue. Not sure if and when I'll feel like doing more debugging on this specific issue myself...
(regarding the recent update, what about labelling GameIssue's (which are now New) with "Type-Game" instead?)
#19 Updated by godisgovernment over 7 years ago
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.
#24 Updated by godisgovernment over 7 years ago
- Status changed from New to Work started
I noticed that these games write SIPoll on every Vblank interrupt.
I got sidetracked and made SI polling be controlled by VI timing (how it actually works on hardware), and accidentally introduced a bug: SI was polled an insanely high amount. However, my bug also fixes this issue. I notice the vi interrupt stuff looks quite sketchy as well, so once I get things squared away I should be able to fix this game as well as make the behavior more accurate :)
#29 Updated by seapancake about 3 years ago
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
#32 Updated by JosJuice about 3 years ago
- Status changed from Accepted to Fixed