Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[OnePad] [Linux] - Analog Sticks - left and right directions malfunction in some games #243

Closed
aphirst opened this issue Aug 16, 2014 · 24 comments

Comments

@aphirst
Copy link
Contributor

aphirst commented Aug 16, 2014

System:

  • Arch Linux x86_64
  • Kernel 3.15 (with -ck patchset) and 3.16 (without)
  • pcsx2 1.2.2 from Arch repositories, and pcsx2-git
  • Onepad 1.1.0 (bundled with pcsx2)

In the game .hack//Infection (SLUS_202.67), the player character can be moved using either the directional pad or the left analog stick, and the camera can be rotated using the right analog stick. In PCSX2 at present, the left and right directions on both of the sticks are un/mis-responsive when set "fully" left/right, and only respond correctly when they are ever-so-slightly diagonal.

Additionally, the 45-degree diagonals also occasionally jitter, instead reporting a pure direction (usually up or down). This causes movement to sometimes jerk in the wrong direction, and makes camera rotation awkward.

I initially thought that this was a malfunctioning controller, but jstest-gtk confirms that the controller analogs work fine (also in other emulators, e.g. Dolphin).

Most interestingly, the erratic behaviour can be reproduced by binding keyboard keys to the 4 analog directions on each stick(!), which proves that my controller is entirely unrelated. Other games seem to work fine (e.g. Ratchet and Clank), and do not exhibit this behaviour, even after thorough testing on my part.

If any additional information is needed, just let me know.

I will try using LilyPad by running PCSX2 in Wine at some point this weekend, but obviously the only native option for GNU/Linux users at present is OnePad.

@aphirst aphirst changed the title OnePad - Analog Sticks - left and right directions malfunction in some games [Linux] [OnePad] - Analog Sticks - left and right directions malfunction in some games Aug 16, 2014
@aphirst aphirst changed the title [Linux] [OnePad] - Analog Sticks - left and right directions malfunction in some games [OnePad] [Linux] - Analog Sticks - left and right directions malfunction in some games Aug 16, 2014
@aphirst
Copy link
Contributor Author

aphirst commented Aug 17, 2014

I have also reported this in the forums.

@gregory38
Copy link
Contributor

In PCSX2 at present,

Did it work on the past?

@aphirst
Copy link
Contributor Author

aphirst commented Aug 22, 2014

Ah, sorry, I didn't mean to imply that I've tested past GNU/Linux builds of PCSX2 with this game, as I haven't.

@gregory38
Copy link
Contributor

http://forums.pcsx2.net/Thread-OnePAD-Dualshock-3-on-Linux

I also had a problem with my left stick left and right not working. You didn't mention this problem but I tracked it down to an issue with sdl, which exists in 1.2 and 2.0. I'll be submitting this patch to the sdl project as well, but this may help anyone doing a google search in the meantime.

@aphirst
Copy link
Contributor Author

aphirst commented Jul 23, 2015

Interesting, I look forward to testing again once we have an appropriately fixed SDL.

@aphirst
Copy link
Contributor Author

aphirst commented Aug 4, 2015

Actually, on second thought, I don't think this behaviour relates to the thing mentioned regarding SDL. I re-tested by binding keyboard keys to the four Left-Analog-Stick principal directions: in this game (and this game alone, it seems), up moves you up, but the other three principal directions all move you down - though pressing two of them causes correct diagonal movement.

Short of a developer already having this game for testing, is there any other information I could give that might help someone work out why onepad causes this strange (mis)behaviour in this game?

@bositman
Copy link
Member

The PR got merged: #667 Care to test again?

@aphirst
Copy link
Contributor Author

aphirst commented Aug 18, 2015

Sure, I'll test it now and see what happens. 😄

@aphirst
Copy link
Contributor Author

aphirst commented Aug 18, 2015

Nope, the problem is still present; and I'd like to re-reemphasise that this problem isn't just when one tries to map a physical analog gamepad to the analog stick in OnePad, but also when one maps keyboard keys to the analog-stick directions.

@gregory38
Copy link
Contributor

Could you test the PR #1476

@aphirst
Copy link
Contributor Author

aphirst commented Jul 24, 2016

@gregory38 Sure! I'll get on it either tonight or tomorrow morning.

@aphirst
Copy link
Contributor Author

aphirst commented Jul 25, 2016

@gregory38 I'm afraid exactly the same bug is still present in the onepad-input-state branch. I did as I did before, namely setting keyboard keys to the four directions of the analog stick, and the left and right directions resulted in me moving downwards in .hack .

EDIT: I also tested it with my controller, mapping the real analog sticks to the analogs in onepad, and I got the same effect whenever the sticks were pointed exactly left or exactly right. Is there any kind of debug information at all I could give to help work out where this problem actually lies?

@gregory38
Copy link
Contributor

I reproduced the issue on my side.

@gregory38
Copy link
Contributor

Hum, I think I found the issue. Axe ranges from 0 to 255. But middle (aka release) state seems to be 127 and not 128 ! I need to double check my code, but I will post a pr soon.

@gregory38
Copy link
Contributor

Ok please retest the branch.

@aphirst
Copy link
Contributor Author

aphirst commented Jul 25, 2016

@gregory38 Will do! Give me about half an hour or so.

@aphirst
Copy link
Contributor Author

aphirst commented Jul 25, 2016

@gregory38 It seems to work! I'll more thoroughly check this later, but I tried with a real analog stick and with keyboard keys, and in both cases I'm now able to actually move the character as expected! I guess this game is just weirdly and sensitively coded with regards to the analog directions.

@gregory38 gregory38 added this to the Release 1.6 milestone Jul 26, 2016
@gregory38
Copy link
Contributor

gregory38 commented Jul 26, 2016

May I ask you a favor. Did you manage to make rumble work ? If yes, could you test if it's still working on the branch.

@aphirst
Copy link
Contributor Author

aphirst commented Jul 26, 2016

@gregory38 I didn't get the chance to test it thoroughly, but I will this afternoon/evening, if that's ultimately what you want. I hadn't enabled rumble, or tested the second controller, I basically just configured the standard controls, opened a save file where I could move my character, and then tested whether the movement worked as expected.

@aphirst
Copy link
Contributor Author

aphirst commented Jul 26, 2016

Update 1: The Rumble feature appears to work for me and my wireless 360 controller, at least in the Options menu of the games I've tested. I'll update further to report on whether it "really" works correctly in-game.

@aphirst
Copy link
Contributor Author

aphirst commented Jul 26, 2016

Update 2: The Rumble feature appears to work properly in-game as well!

@gregory38
Copy link
Contributor

Thanks for the test. So I only need the confirmation that save/load state are working so I can merge the branch.

@aphirst
Copy link
Contributor Author

aphirst commented Jul 27, 2016

@gregory38 Update 3: I did some testing of the save/load state feature (in conjunction with the branch) and it seemed to work, but I only did it one or two times, and indeed I wasn't really trying to strain it (the controller was at rest when I did so). Tonight I can be a bit more thorough.

@gregory38
Copy link
Contributor

Ok. The goal is to fix keep the correct pad detection.

By the way, comment directly in the PR. It would be easier for everybody to follow the info.

LibretroAdmin pushed a commit to libretro/pcsx2 that referenced this issue Mar 30, 2023
* fix bios check in retro_load_game

* Fix crash in cleanup caused by unfinished init
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants