Project

General

Profile

Emulator Issues #960

Auto-fire / Control Stick Problem

Added by nosound.97 about 10 years ago. Updated over 3 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
Controls
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

What steps will reproduce the problem?
1. Running Sonic Heroes
2.
3.

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?
Dolphin r3261

Please provide any additional information below.
Other Gamecube games work properly.


Related issues

Has duplicate Emulator - Emulator Issues #237: Sonic Heroes Controls Messed UpDuplicate

Has duplicate Emulator - Emulator Issues #1330: Autofire controls? (Tatsunoko vs. Capcom)Duplicate

Has duplicate Emulator - Emulator Issues #1542: Zelda Four Sword Adventures ControllerDuplicate

History

#1 Updated by nosound.97 about 10 years ago

Not Sonic Advance, Sonic Heroes :P

#3 Updated by Anonymous over 8 years ago

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

#4 Updated by knuckles500 over 8 years ago

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

I say, fixed.

#5 Updated by skidau over 8 years ago

  • Status changed from New to Fixed

#6 Updated by DimitriPilot3 over 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...

#7 Updated by DimitriPilot3 over 8 years ago

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...

#8 Updated by skidau over 8 years ago

  • Status changed from Fixed to New

This is the unintended auto-fire effect.

#9 Updated by skidau over 8 years ago

issue 1330 has been merged into this issue.

#10 Updated by skidau over 8 years ago

Please test if this issue has been fixed in r6552.

#11 Updated by DimitriPilot3 over 8 years ago

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

#12 Updated by Anonymous over 8 years ago

issue 1542 has been merged into this issue.

#13 Updated by DimitriPilot3 over 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?

#15 Updated by DimitriPilot3 over 8 years ago

issue 237 has been merged into this issue.

#16 Updated by Anonymous about 8 years ago

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?

#17 Updated by DimitriPilot3 about 8 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?)

#18 Updated by DimitriPilot3 about 8 years ago

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

#19 Updated by Anonymous about 8 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.

#20 Updated by Anonymous about 8 years ago

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

#21 Updated by Anonymous about 8 years ago

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

#22 Updated by Anonymous about 8 years ago

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

#23 Updated by Anonymous about 8 years ago

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

#24 Updated by Anonymous about 8 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 :)

#25 Updated by gamerk316 about 7 years ago

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

#26 Updated by Billiard26 over 6 years ago

  • Issue type set to Bug

#27 Updated by JMC4789 over 5 years ago

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

#28 Updated by JMC4789 about 4 years ago

  • Status changed from Work started to Accepted

Still happens even with Native GC Support. That cuts out some of the potential causes, right?

#29 Updated by seapancake over 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

#30 Updated by seapancake over 3 years ago

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

#32 Updated by JosJuice over 3 years ago

  • Status changed from Accepted to Fixed

Also available in: Atom PDF