divVerent
Generic NES-like controller always holds down left, and --gamepad_override doesn't seem to fix it
I have a generic NES-like controller branded "retro power" that the game interprets as always holding down left. The controller works fine in AntiMicroX and Taisei, but for some reason AAAAXY seems to misread the controller. I tried running `./AAAAXY-x86_64.AppImage --gamepad_override "0300000079000000110000001001000012117,Retrolink SNES Controller,platform:Linux,a:b2,b:b1,x:b3,y:b0,back:b8,start:b9,leftshoulder:b4,rightshoulder:b5,dpup:a1,dpleft:a0,dpdown:a1,dpright:a0," (I got the gamepad override string from AntiMicroX. The gamepad doesn't really have that many buttons.), but that seemed to have no effect. Actually, I just now noticed it says "[INFO] gamepad mappings from --gamepad_override applied" regardless of whether I actually use the "--gamepad_override" option.
I have tried "AAAAXY 1.2.280+20220822.2294.9ff4b8b7" and "AAAAXY 1.2.321+20220905.2335.e05b1efe", both via the AppImage, and I am using Trisquel GNU/Linux Nabia (10.0.1) as my operating system. Unfortunately, I could not find a controller that actually works with AAAAXY. I have another controller that came with the NES-like one, and it has a similar problem, and I have a couple of Wii remotes, which do not have the holding-down-left problem, but the D-pad is rotated and none of the buttons jump or pause. The Wii remote D-pad controls the entire operating system for some reason though, so I think the D-pad rotation is a operating system problem or something (Actually, the way the D-pad is rotated would make sense if I held the Wii remote like a TV remote.).
First of all, the mappings are, like all non-debug flags, stored in ~/.config/AAAAXY/config.json - so that not specifying the flag still shows that they're used is fine.
My first suspicion is that the override isn't actually applied to this gamepad; I'll add debug logging to show the actual SDL ID.
Once your mapping is applied, you'll probably be able to locate the bad assignment easily. Having both dpleft and dpright assigned to a0 seems a bit suspicious, BTW; normally one is assigned to -a0 and the other to +a0.
Next release will give you the SDLID of the gamepad that the game library uses - this should help with overriding and fixing the mappings.
That release is out - first thing to check is which ID your controller gets. It is possible that the wrong ID is used and that is why your remapping failed.
Yep, the ID was incorrect. AAAAXY shows it as 03000000790000001100000010010000, and when I change the ID in gamepad_override to that, it no longer acts like I'm always holding down left (but the D-pad doesn't do anything). (I wonder why AntiMicroX shows what it does?).
I tried ./AAAAXY-x86_64.AppImage --gamepad_override "03000000790000001100000010010000,Retrolink SNES Controller,platform:Linux,a:b2,b:b1,back:b8,start:b9,dpup:-a1,dpdown:+a1,dpleft:-a0,dpright:+a0" and then I get the problem with always holding left again.
In jstest-gtk the controller seems fine.
I wonder if something is odd with how this controller reports axis values. Fixes to github.com/hajimehoshi/ebiten may be necessary for this.
Last four digits of the ID looks suspicious. Ebitengine comes with an example program for gamepads - what axis 0 values does it show for left, nothing pressed and right?
On Thu, Sep 15, 2022, 21:09 JacobKfromIRC @.***> wrote:
Yep, the ID was incorrect. AAAAXY shows it as 03000000790000001100000010010000, and when I change the ID in gamepad_override to that, it no longer acts like I'm always holding down left (but the D-pad doesn't do anything). (I wonder why AntiMicroX shows what it does?).
I tried ./AAAAXY-x86_64.AppImage --gamepad_override "03000000790000001100000010010000,Retrolink SNES Controller,platform:Linux,a:b2,b:b1,back:b8,start:b9,dpup:-a1,dpdown:+a1,dpleft:-a0,dpright:+a0" and then I get the problem with always holding left again.
In jstest-gtk the controller seems fine.
— Reply to this email directly, view it on GitHub https://github.com/divVerent/aaaaxy/issues/28#issuecomment-1248802671, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB5NMAKIVD5ASVJ6Q2D4JDV6PCDPANCNFSM6AAAAAAQGIQTHA . You are receiving this because you commented.Message ID: @.***>
I got the Ebitengine gamepad example program running, and the results are interesting. The first thing I noticed is that the 4 values on the left where the D-pad is show "[1.00]" for up and left, and "[0.00]" for down and right. When I hold up or left on the D-pad, the corresponding value changes to "[0.00]", and when I hold down or right, the corresponding value changes to "[1.00]". This explains something I noticed earlier, but didn't mention because I didn't realize it was important: pressing left or right stops the movement to the left. I thought this was just because of how the game handled invalid inputs or something, but then, if I simply hold left on the keyboard (while the NES-like controller is plugged in), it has no effect, and my character continues moving left.
Another thing I noticed is the "Axes:" value at the top. When I'm not holding anything on the gamepad, it shows "0:-0.00, 1:-0.00" which doesn't seem too weird at first, and interacting with the controller works as you'd expect, with holding left resulting in "0:-1.00, 1:-0.00", holding up resulting in "0:-0.00, 1:-1.00", holding right resulting in "0:+1.00, 1:-0.00", and holding down resulting in "0:-0.00, 1:+1.00".
I then unplugged the NES-like controller and plugged in a GameCube controller USB adapter, and although I don't have any GameCube controllers currently, the adapter always acts like 4 controllers are connected, even if you can't actually use them. Here, the Axes are "0:+0.00, 1:+0.00, 2:+0.00, 3:-1.00, 4:-1.00, 5:+0.00", and all the buttons on the gamepad-shaped layout are "0.00" or "--" (where you'd expect, like ZL and select). This suggests there might be a difference between "-0.00" and "+0.00", and I think that might be what the problem is (or at least related to it).
In any case, it seems like it is a bug in Ebiten, as the gamepad test shows the holding left on the gamepad-shaped view.
For the NES-like controller, the ID is 0, SDL ID is 03000000790000001100000010010000 (as AAAAXY reports), and it says "(Standard Layout)" next to that info. Name is "Retro Controller".
Also, the button marked "A" on the controller is button 1, and Ebiten shows that as the down button, out of the group of 4 buttons on the right. The button marked "B" on the controller, which is physically to the left of "A", is button 2, and Ebiten shows that as the right button. Not sure how this is supposed to map to the game, as I know that American game companies typically put the "A" button on the bottom and the "B" button on the right, whereas Japanese companies typically do the reverse, though the NES controller doesn't exactly fit into either of those.
So... first of all, we can always use gamepad definitions to turn unwanted axes off.
As for how the game handles multiple inputs: if any left key is pressed, the player moves left, unless there is also any right key pressed. I might change this to differencing logic instead "more left keys than right keys",
The concrete gamepad appears weird indeed, however it seems only the d-pad data that is broken, while the axes are fine?
Another thing I noticed is the "Axes:" value at the top. When I'm not holding anything on the gamepad, it shows "0:-0.00, 1:-0.00" which doesn't seem too weird at first, and interacting with the controller works as you'd expect, with holding left resulting in "0:-1.00, 1:-0.00", holding up resulting in "0:-0.00, 1:-1.00", holding right resulting in "0:+1.00, 1:-0.00", and holding down resulting in "0:-0.00, 1:+1.00".
This actually looks good; I see good chances that this is something that can be made usable somehow.
Try this string then:
03000000790000001100000010010000,Retrolink SNES Controller,platform:Linux,a:b2,b:b1,back:b8,start:b9,leftx:a0,lefty:a1
This isn't quite correct as it treats the D-pad as an analog stick, but for AAAAXY that will work fine.
As for A/B button mapping, this game should play equally well either way; I intended to have jumping on A as that feels more natural on an Xbox-style pad (although one can also play with the X and Y buttons, which have the same but reversed), but on SMB it was exactly the other way round. I guess it's your preference then :)
I found in Ebitengine source code that the function buttonValue only maps the range [-1, 1] to buttons (like dpad); so normally -1 is treated as "not pressed" and +1 is treated as "pressed". The threshold appears to be -0.76. However if you write +a0, Ebitengine maps [0, 1] to [-1, 1] first, making the threshold 0.12, and if you write -a0, Ebitengine maps [-1, 0] to [-1, 1] first. This appears wrong to me, but nevertheless, you might be able to fix the dpad mappings by inverting (using -a0~ instead of -a0). If that works, might be worth reporting a bug to Ebitengine.
Yes, this seems wrong in Ebitengine (after comparing to SDL source), I'll file a bug. For you, the ideal workaround will be mapping the dpad to leftx and lefty, which should keep working after the fix.
Also, can you try if https://github.com/hajimehoshi/ebiten/pull/2335 fixes everything for you in the gamepad demo of Ebitengine? There was indeed a nasty bug affecting all negative axis mappings.
I tried the leftx/lefty mapping and the -a0~ mapping with AAAAXY 1.2.331+20220912.2345.cbfba5a3 and those both worked fine, and I then deleted config.json to clear the mappings and updated to the latest version (AAAAXY 1.2.336+20220919.2350.a525d576), and the controller still worked fine. I haven't gotten around to testing with the updated ebitengine gamepad test (though, not sure if that makes sense to do given it's fixed in AAAAXY which incorporates ebiten).
I guess this issue can be closed now, as the controller works fine by default now.
Currently, the default is that physical A is jump. I tried using physical B for jump as a test and it felt really strange, but that could just be because I've played a lot of Super Mario Bros., so I'm used to holding down B and pressing A. I think the current mapping should stay. I think Super Mario World (which switched to a 4-face-button controller) started using B to jump, with B at the bottom (where A is on the Xbox pad), so A to jump matches Nintendo for NES and Xbox controllers. But then, A and B are swapped compared to Xbox on modern Nintendo controllers, so it might make more sense to define jump as the lower button rather than a letter, if that's possible.