Zdoom and Gampad Fully Working in MENU with NO KEYBOARD
-
@rodhull You can see how the source install is done from the RetroPie setup scriptmodule for zdoom - https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/ports/zdoom.sh.
-
Yes, that shows how the source is compiled (from https://github.com/RetroPie/zdoom.git) and I have compiled the same source myself to edit the menu.cpp as above - but I was wondering which branch/release the latest binary was compiled from (as is provided by the retropie_setup.sh script)?
I suspect it's likely from a different branch/release to current since it behaves differently once installed.
-
To illustrate further, running the zdoom binary (as installed from the retropie_setup.sh script as of 11th July 2018) from a console with no arguments results in:
$/opt/retropie/ports/zdoom/zdoom
ZDoom <unknown version> - - SDL version
Compiled on Feb 17 2018If I run the version I compiled today from https://github.com/RetroPie/zdoom.git, I get:
$ ./zdoom
ZDoom 2.9pre-2175-g4f21ff275 - 2016-12-29 11:44:07 +0100 - SDL version
Compiled on Jul 11 2018So, there's no way of knowing which version the Retropie-provided binary really is, or what branch/release it comes from. If I knew then I could modify the source knowing it ought to still work as intended...
-
@rodhull said in Zdoom and Gampad Fully Working in MENU with NO KEYBOARD:
ZDoom <unknown version> - - SDL version
The binary is produced with the same script, so it's compiled from the same repository. You can check the history of the file and the reason for which it was forked:
[8221eb8c38954d4ab7e700810feacbf567191e49]
- fork is 2.8.0 with a small compile fix
- versions 2.8.1 + seem to suffer from a collision detection issue
- development has ceased, so we are going to stick with the last known working version
-
OK - so now I'm confused - why does a binary compiled from https://github.com/RetroPie/zdoom.git give 2.9pre-etc. as the version when the fork should have been frozen at 2.8.0 (with a small fix). It shouldn't even take it as far as version 2.8.1.
I'll stand by what I said earlier - if you compile a version from https://github.com/RetroPie/zdoom.git right now, you get a completely different binary to the one supplied by the retropie_setup.sh script - it behaves differently too (Brutal Doom works in the retropie_setup.sh binary, but does not with the freshly compiled version).
Binary version (from retropie_setup.sh):
pi@retropie:/opt/retropie/ports/zdoom $ ls -la
total 6032
drwxr-xr-x 2 root root 4096 Feb 17 20:14 .
drwxr-xr-x 3 root root 4096 Jul 11 14:39 ..
-rwxr-xr-x 1 root root 5530844 Feb 17 20:14 zdoom
-rw-r--r-- 1 root root 632552 Feb 17 20:14 zdoom.pk3Compiled version today from https://github.com/RetroPie/zdoom.git (with only those minute changes to menu.cpp from the OP):
pi@retropie:~/zdoom_latest_git/bin $ ls -la
total 6780
drwxr-xr-x 2 pi pi 4096 Jul 11 18:12 .
drwxr-xr-x 19 pi pi 4096 Jul 11 18:12 ..
-rwxr-xr-x 1 pi pi 6160660 Jul 11 13:29 zdoom
-rw-r--r-- 1 pi pi 768203 Jul 11 13:29 zdoom.pk3The binary and .pk3 are totally different in filesize (and behaviour if the compatibility with Brutal Doom is anything to go by) .
Is there any way to compile from the exact same codebase that the "Install from binary" in retropie_setup.sh provides?
-
This all works, apart from you cannot exit the game by using the menu. Even if you configure the menu_quit to another button, the menu displays but none of the buttons actually allow you to select to quit.
Annoyingly as it's not supported by retroarch configuration, you cannot use the exit hotkeys either.
So the only option is to hard reset the Pi or use a keyboard.
Edit: So it does work, but you have to hammer the d-pad. I am starting to think the input sensitivity is too high as moving between options on the menu often skips. *
In the end I have bound the "exit" console command to a button, just edit the zdoom.ini to contain something like joy16=exit ** -
Hi, it doesn't fit with Brutal Doom MOD installation.
Have I to compile the Brutal Doom .pk3 file?Isn't there a simpler way to accomplish the task?
In zdoom.ini file I can specify:
"joy10=menu_main"
Why there isn't anything as (for example):
joy11=menu_enter
joy12=menu_back
It would be a lot simpler!I don't understand why Zdoom has not this option, I've asked on their forum but still waiting for an answer.
Let me know if someone has found a better way then recompile. -
@rodhull I agree with you as I've just recently tried to get this running. The binary used in the script as of the day of this post WILL run Brutal Doom by making a simple change to the zdoom.ini file AutoLoad config. However, when I used the Menu controller fix and recompiled, I was unable to load Brutal Doom with the same zdoom.ini that was previously working. The following error is produced by the runcommand.sh script:
Script warning, "bd21RC8.pk3:player.txt"
Invalid face '' for 'Doomer';
If the latest commit to the repo is in fact what was used to build the binary installed via retropie-setup.sh script, then the problem will be harder to fix. But I am suspicious of such a size change to the binary with only a few lines of code changed. I can start by digging through commits, but any additional info or help on this matter from the community would be appreciated.
Edit: So I looked into it and yes, 2.8.0 appears to be the last working commit. So if that's the case, it was published on Feb 4, 2016. There is a commit on that day and is the possible "last working version" we're looking for.
Commit hash:56359b6f233f538b8cbcec093af93a19d66fabed
I'll experiment with this as soon as I can and see if 1) it produces the same binary from the RetroPie script and 2) do the menu edits works with it. I will provide an update with steps if this works. -
I got it working! And here's how I did it:
First, after performing this step:
git clone https://github.com/RetroPie/zdoom.git retropie
execute this:
cd retropie git checkout retropie
Now make the edits provided in the original post.
After running thecmake . -DCMAKE_BUILD_TYPE=Release
step, do the following:- If you don't already have
ccmake
, executesudo apt-get install cmake-curses-gui
from the command line. - Run ccmake -->
ccmake ./
- In the GUI that launches, navigate down to
NO_ASM
and hit Enter to set it toON
- Press
c
to run the configure step, thenq
to exit
Now continue from the
make
step from the original post, and everything should work! - If you don't already have
-
Hello guys,
I wanted to thank RapidEdwin08 and RetroS3xual for all the useful info. It allowed me to understand how ZDoom works, and gave me a start point for what I'm presenting now: gamepad buttons finally working in menus, without the need for "Enter" and "Esc" keys, and with "left" and "right" functioning as they should, so the game doesn't need a keyboard anymore. You can download the binaries here:
https://github.com/protocultor/zdoom/releases/tag/2.8.11
For those who want to see the changes, here they are:
https://github.com/protocultor/zdoom/commit/4b129d827233b8bb42ce64e8b74231b9906c0f78...and now I'm hoping to see these changes officially in RetroPie in the future:
https://github.com/RetroPie/zdoom/pull/2 -
Pretty excited for this.
-
@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 :( -
@Protocultor Have you tried to ring the Bell @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!
-
@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.
-
Thanks for the replies guys!
-
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?
-
@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:
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.
-
@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 throughRetropie-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 inREADME.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. -
@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.
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.