Zdoom and Gampad Fully Working in MENU with NO KEYBOARD

Quackwalks

Pretty excited for this.

Protocultor

@RetroS3xual I forgot to say: in the ccmake GUI, you can also enable NO_GTK. This made the executable 200kb smaller for me, with no side effects and able to run Brutal Doom v21 RC8.

I released updated binaries:

https://github.com/protocultor/zdoom/releases/tag/2.8.12

This will allow the "main menu" button to work after you've finished an episode. By default, it's joy9 (SELECT in the gamepads I've seen) but you can change it in the controls. The following is what made it work, and is included in the pull request:
https://github.com/protocultor/zdoom/commit/74f3c8140710cd002c030c8c0f3100c2b24fc7d4
It's a shame that nobody in the RetroPie team has seen the PR yet :(

Rion

@Protocultor Have you tried to ring the Bell @BuZz ?

BuZz

@Rion I saw the PR. Just busy :-) I may merge PR to a new branch but my current priorities are getting new release out and I'm short on time etc :-)

The PR is appreciated and will get reviewed in time. Cheers!

RetroS3xual

@Protocultor thank you so much for doing this! I downloaded your build and can say it's working great. :) I've only played a few levels of Brutal Doom (working) but I was able to navigate the menus with the buttons as expected and could proceed with the end-level screen. Looking forward to this being added on to the RetroPie-Setup script.

Protocultor

Thanks for the replies guys!

RetroFreak89

I dont want to change the subject but im working on a doom pi project im curious is zdoom the best performance source port to use on the pi?

Solid One

@Protocultor I have a RPI2 and tried to compile manually zdoom from your github repository, in order to see if the controller mappings would work on my PS2 controllers plugged through this adapter:
alt text

However, it didn't worked. Although I could map start button to "main_menu" (and then avoid pressing ESC on the keyboard), the same couldn't be said for D-pad Left / Right to "Enter" / "Menu Back", so I couldn't select any menu options without having to resort to my keyboard.

I tried turning analog on and off (by pressing the button between Select and Start) and then pressing all controller buttons. Didn't worked. Tried pressing all buttons from my controller and again it didn't worked. I even tried tweaking some controller mappings manually in zdoom.ini, to no avail.

After reading a bit your code changes in github, am I right to assume that the controller mappings didn't worked because I'm using a kinda generic controller adapter? Would it work if I used a wired Xbox 360 controller for that test?

Besides, I even got an issue that, although unrelated to the controllers, was preventing zdoom process to close when I exit the game. Had to press Ctrl+C from keyboard to do that, and without keyboard, I couldn't go back to EmulationStation after closing zdoom, so if it wasn't for my keyboard at my side, I would be forced to hard reset my RPi. That didn't happened on the other binaries compiled directly from RetroPie-Setup.

Protocultor

@Solid-One, first of all: when you compiled my repo, did you change to the retropie branch? All my changes are in that branch only. Also, I've only tested with a RPI 3B+; a RPI 2 shouldn't have any problems, but maybe it's something to consider.

If you have any doubts about the compilation process, you can instead download the binaries here:
https://github.com/protocultor/zdoom/releases/tag/2.8.12.2
Unzip its contents to /opt/retropie/ports/zdoom/. Backup if you want, but you can restore the original version by reinstalling zdoom through Retropie-Setup.sh

About that adapter of yours, I have to say that had one of those (or it was extremely similar) and I hated it. When connecting two controllers there was "interference", the input of one controller affected the other. Also, button layout was all over the place, made more evident when connecting to a PS3 console, where Square and Triangle buttons were exchanged by X and Circle, or something like that.

My solution to those problems was changing that adapter to 2 that connected only one controller at a time, and they were black. Don't remember if it's one of these:
https://www.aliexpress.com/item/For-Sony-PS1-PS2-Play-Station-2-Joypad-GamePad-to-PS3-PC-USB-Games-Controller-Adapter/32521537537.html
https://www.aliexpress.com/item/High-Quality-1pc-USB-Adapter-Converter-Cable-For-Gaming-Controller-For-PS2-to-For-PS3-PC/32789486872.html
...or maybe a even cheaper version, but they got the job done.

In any case, as zdoom uses SDL2 for input, you can check if your controllers work properly with the following project:
https://github.com/Grumbel/sdl-jstest
A couple of warnings:
1.- You'll have to compile it manually, following instructions in README.md
2.- sdl2-jstest has a problem with RPI where the interrupt signal (Ctrl-C) is not properly recognized, so you'll have to kill the program manually by connecting through SSH and killing the process (or just unplug the Pi, something not very recommended).

Still, I'm assuming you are using your adapter normally with, let's say, Retroarch emulators (lr-something). Please keep me updated if you make any progress with this.

Solid One

@Protocultor Retropie branch? Aww crap. I hadn't specified any, so I've probably compiled the source from master branch. That explains why I haven't noticed anything different between the original binary and yours. I'll try recompiling it again later, from that branch.

And I've tested your binaries before compiling from source on my side. However, they didn't worked on my RPi2. I got a error that seems to be related to different RPi versions. Since you got a RPi3 and I've a RPi2, I guess that's why it didn't worked. Maybe a binary compiled directly from a RPi2 such as mine would work.

About my PS2 adapter, I would say I got lucky. I have two units of this adapter, and both are working just fine, never getting any interference issues even when I plugged four PS2 controllers in two adapters, for playing games such as Super Bomberman 4 and Mario Kart 64. However, I can confirm the different button layout, when compared to Xbox 360 controllers per example. But since most of my games in my RPi2 are emulated through RetroArch, and I've configured it through EmulationStation, everything seems just fine. I was able to even configure the left analog to move / strafe and the right analog to turn, in N64 FPS games such as Doom 64 and Duke Nukem Zero Hour, and it works just fine.

About zdoom controller support, except for menu navigation, everything works just fine on my PS2 controllers. I can map the left analog to move / strafe, right analog to turn / aim, R2 to shoot, D-pad to change weapons / inventory, square to jump, cross to open doors, circle to crouch, and so on. I've even got to the point of configuring extra actions for mods such as Brutal Doom and Real Guns Hardcore: L2 to aim, triangle to reload, right analog stick to kick and R1 to throw grenades.

Anyway, I'll see if I can compile it again and I'll tell you the results.

Solid One

Just recompiled it two days ago, from retropie branch instead of master. Now my controller is working like a charm. I can choose options with cross button, go back with circle button, and access main menu by pressing start. Now I can play zdoom mods only from a gamepad. Thanks!

G30FF

@Protocultor Sorry to bother, but I tried to install your binary build of 2.8.12.2 on my Pi 3 B+. I started with a fresh zdoom.ini. I've tried it with two different controllers: a SNES30 Pro connected via the 8bitdo USB wireless adapter, and the SN30 Pro Wired Controller (the first registers as a PS4 controller, and the second registers as a 360 controller). I can navigate the menu, but I have two major problems:

On both controllers, the left thumb stick is acting as if up and right on the left thumbstick is constantly being pressed, so the menu is constantly scrolling up, and if I get into the game, I am constantly looking up and moving forward.
I can't open the menu while in-game.

Is there anything I'm doing wrong? I tried building from source on the retropie branch, but I have the same results whether I build form source or download the binary build.

Protocultor

@G30FF I don't even know how to start, you are the first person that describes me something like it. One question: does this situation happen in-game with the original executable (without my changes)?

Solid One

For opening menus ingame, see here.

About your issue with left analog stick constantly pressing up or right: It happened to me too on menu navigation, when I tested with another PS2 controller with a loose left analog stick. Zdoom allows menu navigation through left analog stick, but it's super sensitive: the minor axis movement done in the stick is detected, and it can result in the controller keeping pressing up or down constantly. It only stops when I center the analog left stick manually with my thumb. It happened both on original Zdoom, and on the binary containing the changes made by @Protocultor.

It happened because there's no deadzone values being applied to the axes that corresponds to the left analog stick, when it's used specifically for menu navigation. There's deadzone only for other actions besides menu navigation, such as character movement per se.

For common users, there's some solutions / workarounds for this issue:

Fix the looseness in the left analog stick of your controller (If there's any);
Try centering the left analog stick manually with your thumb, when navigating through menus;
Test Zdoom with another controller, by unplugging all other controls you have, and plugging only the one you're going to use.

For developers, a possible solution would be implementing deadzone support in menu navigation (If not done yet), or allowing menu navigation not from controller axes, but controller hats (d-pad, per example).

Similarly to what @Protocultor done in Zdoom, I'm trying to implement menu navigation in Doom Legacy, and I'm using hats for pressing up, down, left or right in the menus. For the moment, I haven't got that issue yet (besides testing with controllers with only axes and no hats, but that's another discussion).

Protocultor

@Solid-One thanks for the explanation, that makes a lot more sense.
I'll mess around with the code in the next few weeks to see if I can add a fixed amount of deadzone to menu/GUI actions only. After all, they are meant to be controlled with the cursor keys; analog input is no advantage here.

G30FF

For the in-game issues, I want to report that it's my bad, and has nothing to do with your changes. My ZDoom analog settings were messed up, so it was registering one axis as constantly being pressed. I've fixed that and it seems to be working just fine now. I thought the issues were related because it seemed to be constantly pressing up on both the menu and in-game, but I see that wasn't the case.

The only issue I have remaining is with the analog on the menu, although I am able to get it to stop registering the analog presses if I move the analog stick around for a while after loading ZDoom. That however only works inconsistently.

Either way, please disregard my comments about the issues in-game. I did that to myself!

EDIT: I can consistently get the menu analog issue to stop after it starts by rotating the left analog stick in a circle. That seems to make it stop until the next load of ZDoom.

corezon

@BuZz Any chance this could get merged? It has been an open PR since April.

Thanks for all your hard work!

BuZz

@corezon This will need to be revisited. We are moving to lzdoom and zdoom is being removed (it's already happened on our fkms_rpi4 development branch).

This is based of https://github.com/drfrag666/gzdoom - branch 3.82

Our fork was a temporary measure really and was only in place due to bugs with the upstream code (which I believe were possibly caused by fast-math optimisations).

bassybeats

Did anyone end up looking back into this for lzdoom? Finally got lzdoom and brutal doom going and realised this won't work with it.

Protocultor

@bassybeats I did. The changes in ZDoom worked with LZDoom with some slight fixes:
https://github.com/protocultor/gzdoom/commit/8ba7e49184c2be58c0ad03a7602dcd2c4b0ff6fd

Binaries for Rpi3B+:
https://github.com/protocultor/gzdoom/releases/latest

The unfortunate issue is that there's no actual repository for the RPi "version" of LZDoom, since the source to compile comes from a tag; there's not even a branch to work with. So I had to fork the repo and create a branch from that tag to be able to apply the changes.

If you have to compile it, follow these steps:

cd ~
mkdir lzdoom_joy
cd lzdoom_joy
# Clone LZDoom from my repo and branch
git clone https://github.com/protocultor/gzdoom.git --branch joypad_menu --depth 1
cd gzdoom
c="$(lscpu -p | grep -v '#' | sort -u -t , -k 2,4 | wc -l)" ; [ "$c" -eq 0 ] && c=1
# In the following, remove "-DUSE_ARMV8=On" if you're not using a Rpi3 or later model
cmake -DCMAKE_BUILD_TYPE=Release -DNO_GTK=On -DUSE_ARMV8=On .
# The following will take A LOT of time
make -j$c
# After a long wait... its backup time
cd /opt/retropie/ports/lzdoom
sudo mv brightmaps.pk3 brightmaps.pk3.BAK
sudo mv game_support.pk3 game_support.pk3.BAK
sudo mv lights.pk3 lights.pk3.BAK
sudo mv lzdoom.pk3 lzdoom.pk3.BAK
sudo mv lzdoom lzdoom.BAK
sudo mv soundfonts/lzdoom.sf2 soundfonts/lzdoom.sf2.BAK
# ...and finally, replace the installed lzdoom with what you compiled
sudo cp ~/lzdoom_joy/gzdoom/*.pk3 /opt/retropie/ports/lzdoom/
sudo cp ~/lzdoom_joy/gzdoom/lzdoom /opt/retropie/ports/lzdoom/
sudo cp ~/lzdoom_joy/gzdoom/soundfonts/lzdoom.sf2 /opt/retropie/ports/lzdoom/soundfonts/

You still have to do a first-time configuration with the keyboard, at least to increase the deadzone with some gamepads.

Note that, if you don't have sound, you must create the file .alsoftrc in your home (~) with the following content:

[alsa]
mmap = false

(Thanks to @RussellB for the solution to this: https://retropie.org.uk/forum/post/234245)

EDIT: updated instructions for the recreated branch, which is now based on 3.86a.