Duke Nukem 3D and Shadow Warrior source ports for old Pis

Protocultor

If you have a RPi 3 or lower, want to play Duke Nukem 3D, and wonder why EDuke32 runs so slowly, you should check out JFDuke3D.

This source port is very old, in fact EDuke32 started as a fork of it. However, JonoF, its original author, never abandoned it, and around 2018 he added an OpenGL ES 2 renderer, which makes it blazing fast on the Pi. In a 3B+, it runs in 1280x720 resolution, at what feels like 60 fps (at worst, at a lot greater than the ~15 fps EDuke32 gives me). Not to mention, in actual full screen.

Since it works with no issues on the legacy driver, and includes SDL2 gamepad controls, calls my attention that no one has tried to include it before in RetroPie, so I made a pull request for this.

Also, from the same author, there's a Shadow Warrior port, JFSW, that uses the same Build engine modifications and improvements. This one was already added by @ExarKunIv in RetroPie-Extra, but my version of the script makes it able to run in the rest of the supported platforms by RetroPie, and not only the Pi 4/5. I still stole from him the detection and addition of the game's expansions; I hope he doesn't mind :)

Compared to JFDuke3D, this port is a little bit slower, but that's because of the Voxel Sprites support; disabling it makes this to run as fast as that port.

If you don't want to wait for the pull request to be accepted, here are the scripts to install them:

Copy them to ~/RetroPie-Setup/scriptmodules/ports/, run the setup, and search for the experimental packages jfduke3d and jfsw. Note that the former is needed by the latter, so if you want only to try Shadow Warrior, you'll still need both scripts to be copied (it's not necessary to install Duke 3D).

RapidEdwin08

@Protocultor Thanks!
Will give this a try for sure.

newhinton

Hi!

Your PR on github for the JFDuke3D-port works great! No changes required for the build, it works out of the box.

However, on my Pi4 i have the same issue as i have with the default eduke32.

I am using an xbox 360 controller, but in both emulators the right x-axis does not register. (someone else mentioned this issue in some other thread, but i cant find it right now)

The axis works fine in other games, just not doom. Do you know why that might be and how to fix it?

Thanks for your help either way, and for providing the script in the first place.

Protocultor

@newhinton hi! It's good that you decided to post here.
Since your controller works fine in other ports and emulators, I'm assuming you don't have a hardware issue.

Your problem is uncommon, but not completely unheard of. Download this file:
https://raw.githubusercontent.com/gabomdq/SDL_GameControllerDB/master/gamecontrollerdb.txt
...and save it with the same name, gamecontrollerdb.txt, to ~/RetroPie/roms/ports/duke3d, or wherever your Duke Nukem 3D files are installed.
If this doesn't help you, please comment. There are alternatives to try.

And because you casually name-dropped it, I'll help you with Doom.
If you are talking about the LZDoom port, please check its controls' documentation:
https://retropie.org.uk/docs/Doom/#zdoom-controls
...and read with care how you should assign its Axes; I believe the documentation is right with the Axis 3 and 4 assignment. If it's not, see what happens if you assign Turning to other axis. Try 5 or 6, and see that you are not turning with the triggers! Identifying properly what every axis does is crucial.

newhinton

@Protocultor

And because you casually name-dropped it, I'll help you with Doom.

Ahh sorry, i got confused there for a moment, sorry. I am trying to get doom, duke and wolfenstein running, but doom is actually the only one working, though i had to fight a bit with the controls until i found out that retro-arch has a "modern controller"-style option which works flawlessly out of the box.

Though both duke-ports have the same axis issue.
And sadly the gamecontrollerdb.txt didn't change anything.
Another note, the x-axis is actually inverted. Though that might not matter, if it is not related to the issue. (Sorry, i swapped those. Up and Down, or X, is working, while Left and Right, or Y is stuck)

Protocultor

@newhinton said in Duke Nukem 3D and Shadow Warrior source ports for old Pis:

Though both duke-ports have the same axis issue.

Another note, the x-axis is actually inverted. Though that might not matter, if it is not related to the issue. (Sorry, i swapped those. Up and Down, or X, is working, while Left and Right, or Y is stuck)

Wait, what?
Both Duke ports use SDL2 for its gamepad input (SDL_GameController specifically), so, its expected for both to have the same issue.
But you first said that "the X-axis does not register", then you said that "the X-axis is inverted". So, what is it?
Most importantly, you said "Up and Down, or X, is working, while Left and Right, or Y is stuck".
Just in case, when someone refers to the X-axis, they mean the horizontal axis, meaning "left and right". The Y-axis is the vertical one, "up and down".
"Sorry, i swapped those". Where? How? What do you mean by this?
What I understand is that you are used to play with the vertical axis inverted in FPS games, and tried to universally invert them???
Do you invert the horizontal axis also? (Some people do this, believe it or not).
Please, rephrase your problem, because I believe there's more going on with your system.

sleve_mcdichael

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

https://retropie.org.uk/forum/topic/30479/eduke32-controller-issue-right-analog-x-axis-not-responding-at-all

RapidEdwin08

@sleve_mcdichael does it have same Axes issue with other ports as well, like eduke32, yquake2, ROTT, ect?

sleve_mcdichael

@RapidEdwin08 I have only seen it in eduke32, but I don't have those others.

newhinton

@Protocultor

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

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

RapidEdwin08

@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 JoyPads

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

Make 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 things

Re-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 #3379

Protocultor

@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/js0 and 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.

mitu

@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 #3379

If it's indeed this issue, then you don't need to re-compile anything - just remove the /etc/modprobe.d/xpad.conf file and the triggers as buttons option will no longer apply. You need to restart the system, so that xpad is 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.

newhinton

@Protocultor

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

After 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?

mitu

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

newhinton

@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!

mitu

@newhinton we have that in the FAQ, but I guess it can be added to the Xbox360 controller page also.

Protocultor

@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? :)