Duke Nukem 3D and Shadow Warrior source ports for old Pis
-
@newhinton said in Duke Nukem 3D and Shadow Warrior source ports for old Pis:
I am using an xbox 360 controller, but in both emulators the right x-axis does not register.
I was only able to solve this by using a different controller (Logitech wireless works out the box).
-
@sleve_mcdichael does it have same Axes issue with other ports as well, like eduke32, yquake2, ROTT, ect?
-
@RapidEdwin08 I have only seen it in eduke32, but I don't have those others.
-
But you first said that "the X-axis does not register", then you said that "the X-axis is inverted". So, what is it?
In my initial post i wrote:
I am using an xbox 360 controller, but in both emulators the right x-axis does not register.
Which i thought was wrong in my second post because it is there that i actually got confused about axis-naming. I will try to rephrase it and specify my findings.
I did a test with a different controller, an 8bitdo sn30pro. With that controller, i can start the game, configure the right stick to my liking and it properly works.
Now, after exiting the game properly, and then disconnecting the 8bitdo, i can start the game with the xbox-controller.
While the in-game controller mapping is known-good, the x-axis (left/right) of the right stick is again not recognized.
I am using the following settings for duke:RightX, Turning, Scale +1 RightY, Looking, Scale -1The above settings are working for the 8bitdo, but not the xbox controller.
Those settings result in the vertical axis to turn the character. It feels like the xbox' right stick behaves like it is rotated in comparison to the 8bitdo.Just to confirm my findings, i tested both controllers in the n64 emulator where both right sticks behaved correctly and identically.
I have also tested both controllers with
jstest /dev/input/js*with no notable difference besides the deadzone beeing a lot smaller on the 8bitdo. -
@sleve_mcdichael I've experienced this issue and resolved by removing trigmapping as buttons if that applies to you.
Default [xpad] Driver contains [01_enable_leds_and_trigmapping.diff]
This Patch can cause Issues with SDL Right Stick Axis on some JoyPadsWith trigmapping Patch ENABLED the Triggers are Mapped as Buttons.
You can try to disable this by manually editing the diff
File:
/home/pi/RetroPie-Setup/scriptmodules/supplementary/xpad/01_enable_leds_and_trigmapping.diffMake a Backup.
Modify [01_enable_leds_and_trigmapping.diff] to look like this:--- a/xpad.c 2018-08-22 14:49:37.237360461 +0000 +++ b/xpad.c 2018-08-22 14:49:37.293357132 +0000 @@ -86,6 +86,8 @@ #define XPAD_PKT_LEN 64 +#define CONFIG_JOYSTICK_XPAD_LEDS 1 + /* * xbox d-pads should map to buttons, as is required for DDR pads * but we map them to axes when possible to simplify thingsRe-Install xpad Driver again from Source with those changes.
Reset your Controller Inputs for Emulationstation.
When you Re-Map the After the changes, your Triggers should be mapped as Axes instead of Buttons.Try eduke32 JFDuke3D after with Triggers mapped as Axes at that point.
More Info here: https://github.com/RetroPie/RetroPie-Setup/issues/3379
xpad triggers_to_buttons=1 patch breaks SDL gamepad mappings #3379Raspberry Pi B, Pi B+, Pi2 B, Pi3 B, Pi3 B+, Pi Zero W, Pi4 (4GB/8GB), Pi5 (4GB), Pi Zero 2 W, GPi V1, minisforum GK50 / RetroPie 4.8.x
-
@newhinton said in Duke Nukem 3D and Shadow Warrior source ports for old Pis:
While the in-game controller mapping is known-good, the x-axis (left/right) of the right stick is again not recognized.
...
Those settings result in the vertical axis to turn the character. It feels like the xbox' right stick behaves like it is rotated in comparison to the 8bitdo.I have tested both controllers with
jstest /dev/input/js*with no notable difference besides the deadzone beeing a lot smaller on the 8bitdo.Ok, so the problem is still the same: X axis of right stick does not respond / "does not exist", and additionally the Y axis seems to be the actual "X axis".
Then, I need to ask you if you can install
yquake2(Quake II). It's on the experimental packages, and has binaries and a demo available, so you don't have to add anything on your side to play.I need you to begin the game, see if you have the same problem (unrecognized X axis of right stick, turning with Y axis), and exit the game.
Then, I want you to post here a certain section of the console log, located in~/.yq2/baseq2/qconsole.log; I just want the "input initialization" section. For reference, this is mine, using a PS4 controller:------- input initialization ------- 1 joysticks were found. Trying joystick 1, 'Sony Computer Entertainment Wireless Controller' Buttons = 13, Axes = 6, Hats = 1 Enabled as Game Controller, settings: 030000004c050000c405000011810000,PS4 Controller,a:b0,b:b1,back:b8,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b10,leftshoulder:b4,leftstick:b11,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b12,righttrigger:a5,rightx:a3,righty:a4,start:b9,x:b3,y:b2, Joystick/Mouse haptic: * 16 effects * 16 haptic effects at the same time * 2 haptic axis Rumble support available. ------------------------------------I want you to copy what appears to you. Finally, do a
jstest /dev/input/js0and tell me which axes are your right stick's X and Y; you'll identify them because will be the only ones changing when you move it side to side, or up and down.I know I'm asking a lot, but I still believe it has to do with a wrong mapping of your right stick axes by SDL_GameController. And the good thing about Yamagi Quake 2 is that is very open with this kind of stuff.
-
@RapidEdwin08 said in Duke Nukem 3D and Shadow Warrior source ports for old Pis:
More Info here: https://github.com/RetroPie/RetroPie-Setup/issues/3379
xpad triggers_to_buttons=1 patch breaks SDL gamepad mappings #3379If it's indeed this issue, then you don't need to re-compile anything - just remove the
/etc/modprobe.d/xpad.conffile and the triggers as buttons option will no longer apply. You need to restart the system, so thatxpadis reloaded with the new options.EDIT: since this will change the # of axis and buttons available, you need to also re-configure the gamepad in EmulationStation.
-
I need you to begin the game, see if you have the same problem (unrecognized X axis of right stick, turning with Y axis), and exit the game.
Yes i do, same as before. One notable event is that quake logs the following while moving the right stick to the left:
Trig_left(258) is unbound, hit F4 to set.------- input initialization ------- 1 joysticks were found. Trying joystick 1, 'Xbox 360 Wireless Receiver' Buttons = 17, Axes = 4, Hats = 1 Enabled as Game Controller, settings: 030000005e040000a102000000010000,X360 Wireless Controller,a:b0,b:b1,back:b6,dpdown:b14,dpleft:b11,dpright:b12,dpup:b13,guide:b8,leftshoulder:b4,leftstick:b9,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b10,righttrigger:a5,rightx:a3,righty:a4,start:b7,x:b2,y:b3, Joystick/Mouse haptic: * 16 effects * 16 haptic effects at the same time * 2 haptic axis Rumble support available. ------------------------------------I know I'm asking a lot,
To be honest, you are not. You are helping me with an more or less unrelated issue, on your own time, and that is quite amazing. Thank you for your time, and just ask away!
jstest:
Right stick: X-Axis left: -2 X-Axis right: +2 Y-Axis up: -3 Y-Axis down: +3 Left Shoulder Trigger: 6 Right Shoulder Trigger: 7After testing, i tried @mitu fix, and it works, jstest reports a different mapping and the axis are swapped.
Right stick: X-Axis left: -3 X-Axis right: +3 Y-Axis up: -4 Y-Axis down: +4 Left Shoulder Trigger: -2 to +2 (now axis instead of button) Right Shoulder Trigger: -5 to +5 (now axis instead of button)So, i got a fix. Is this the proper one, or is this a workaround with sideeffects that i might need to know about?
-
@newhinton said in Duke Nukem 3D and Shadow Warrior source ports for old Pis:
So, i got a fix. Is this the proper one, or is this a workaround with sideeffects that i might need to know about?
I think this is the proper fix - this synchronizes the gamepad's input with the SDL's GameControllerDB mapping. It will also fix other SDL2's ports that use the GameController system.
The side-effect is the fact that you'll have to reconfigure your gamepad in EmulationStation and this willalso change the mappings in other emulators (i.e. RetroArch, Mupen64Plus).
-
@mitu If you dont mind, i will open a PR to the Documentation adding this behaviour to the xbox 360 controller.
To both of you, thank you very much for your time and help!
-
@newhinton we have that in the FAQ, but I guess it can be added to the Xbox360 controller page also.
-
@mitu said in Duke Nukem 3D and Shadow Warrior source ports for old Pis:
I think this is the proper fix - this synchronizes the gamepad's input with the SDL's GameControllerDB mapping. It will also fix other SDL2's ports that use the GameController system.
I agree, this is pretty much the fix for this.
My original idea was for @newhinton to use another
gamecontrollerdb.txt, adapted to what the controller reported initially for the right stick and triggers:030000005e040000a102000000010000,X360 Wireless Controller,a:b0,b:b1,back:b6,dpdown:b14,dpleft:b11,dpright:b12,dpup:b13,guide:b8,leftshoulder:b4,leftstick:b9,lefttrigger:b6,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b10,righttrigger:b7,rightx:a2,righty:a3,start:b7,x:b2,y:b3,platform:Linux,...but this forces to use this file in every single SDL2 game/port/emulator, needs further corrections (triggers are now duplicated with start and back), and the default mapping exists for a reason: those axes and buttons are what the native driver always have reported originally for this controller. I had no idea that xpad could be so intrusive. So yeah, the problem is fixed. Thanks guys for the knowledge.
So, since there's no issue with JonoF's ports, can my PR be evaluated now? :)
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.