Right Analog stick takes higher precedence than left analog stick when both combined in gamepad mapping

[Sumeet-R]

What happens?

Most of the PSP games such as Prince of persia series, Chili Con Carnage etc requires camera controls and mostly they are combination of [L-pad] + [Left Analog Stick(LAS)] for camera movement and just LAS for character movements. Modern gamepads have Right Analog Sticks(RAS) which usually best known for camera controls, and PPSSPP Emulator does recognises the RAS from the gamepad, however when Analog Combinations being used under Control Mappings to achieve Camera Controls with RAS as shown below, the RAS then takes highest precedence upon LAS, due to which only camera is being controlled with key combined RAS but not character movements using just LAS.

What should happen?

I know PSP models support just one analog, but will there be any fix for this issue as in Emulation it might be possible to get both working since it supports control mapping combinations for other buttons such as L-PADs or R-PADs even when PSPs support just single L-PAD and R-PAD, for eg- I use both R-PAD1 and R-PAD2 for same purpose for shooting simultaneously whichever is near, similarly L-PAD1 and L-PAD2 for blocking or reloading.

What are you using?

I am using Live Tech Yo Man! Gamepad connected to Redmi Note 7s where I am running the latest build of PPSSPP version 1.11.3

[LunaMoo]

Do you actually mean a problem of emulation? Because from your description and my personal memory of some games fitting what you're describing it's simply a feature of the game, because a lot of games which require pressing some key to control camera are actually locking other controls, aka you can only control camera when standing still in those games, sometimes are allowed to shoot or use some interaction buttons, but not movement. If that's what you're speaking about, then no, this is not an emulator issue, but a game design and can't be changed by any emulator magic.

You could however learn MIPS assembly and a bit about how games work and patch the games itself. Changing controls in any way, even adding real analog support isn't that hard or unsafe as for example changing framerate of games, but it can take much more time and as such isn't as common or popular.

[Sumeet-R]

No, not meant as what you are referring to. Some games does allow to have both character as well as camera movement simultaneously, but that's not an issue and I understand that it depends upon game feature, but actual issue is gamepad mapping freezes the left Analog stick when right Analog stick is mapped with the movements. So even when you are not using/pressing RAS during game, the LAS doesn't work at all. So definitely emulation issue.

[unknownbrackets]

Are you sure? Have you actually played the game on a PSP and seen this? If so, how?

Think about it logically. The way the game works is like this:

-> The user has moved the analog nub (there's only one on the PSP) -> Is the L button currently pressed? ---> YES, move the camera. Done. ---> NO, move the character. Done.

This is game logic, not emulator coding. What would the game look at to move the character and the camera at the same time? I understand that the game's engine may support moving the camera and character simultaneously, but even that's not sure - PSP games often used custom engines. And crazy things might break if we tried to hack into the game and make assumptions about how the engine works and randomly change internals inside the game. That's asking for a game patch.

If you haven't ever actually played PSP games on a PSP, I can understand how you'd think it's totally stupid to only be able to do one of camera or character movement at a time. Even when the PSP was new and I was using it, I thought the same thing. It depended on the game how camera movement worked.

But that's just how they worked.

A bunch of NES games use "passwords" to save. That was annoying too. But it's just how the games were programmed. If you want someone to reprogram the games, that's something for custom game hacking. Saying it's an emulation issue won't make it true.

-[Unknown]

[Sumeet-R]

@unknownbrackets I think you don't understand my issue at all.

I am not using camera and movement simultaneously, what I am trying to achieve is to control camera using Right Analog stick that includes mapping combinations of L-PAd and Movement. But when this combo is done, I am not able to move character with Left Analog stick even without any other buttons pressed. So there is no simultaneous here, it just that after the combo mapping, Left Analog stick completely stops to work. Hope what I mean now? I can show the actual issue with a video if required in case its still not clear?

[LunaMoo]

In that case I think it's pretty much the same thing as #14340 except for gamepad and less severe as affecting only thumbstick due to high deadzone being set to buttons when translating input from analog to button(this does not exist for mouse due to complains and other issue).

Basically if you have 2 different sticks mapped to thumbstick, they both send input and if 0 input is not ignored(it really should not be as that causes other issue of "flowing stick") if you stop moving one stick it still will send 0, negating the movement of another.

As Henrik commented in that other issue, we'd have to combine the input somehow before sending it to game, ultimately this would have to affect all inputs mapped to same PSP inputs.

[unknownbrackets]

Got it, sorry. You're not saying that you want to be able to move both sticks simultaneously, just that you want them mapped simultaneously but the right analog (even when not moving it) prevents the left analog position from being properly considered.

Pretty sure that doesn't happen on Windows, sending a change that may help.

-[Unknown]

[LunaMoo]

You sure this wasn't happening on windows for you? I was able to reproduce it earlier and now not only this, but also #14340 appear to be solved.

[unknownbrackets]

Hmm, I didn't test carefully, but XInput and DirectInput were already trying to prevent duplicate events, I just moved it to a common place all platforms will use. That said, the mouse indeed was not ignoring duplicates. It also compares with lower resolution than XInput and DirectInput did, so if you had a particularly jittery analog, this new way might work better even on Windows.

Anywya, given this seemed to fix it, I'll close. If it's still happening in the latest git builds on some platforms, we can reopen.

-[Unknown]