Doom Pi Project Need Advise

Rion

@tpo1990
ReMooD is a Doom source port of Doom Legacy 1.42 support 4-player split screen support but sadly the project was stopped. Github

Searching for ReMooD forks i found

Edward850's BananaSplit fork of Eternity

tpo1990

@Rion said in Doom Pi Project Need Advise:

@tpo1990
ReMooD is a Doom source port of Doom Legacy 1.42 support 4-player split screen support but sadly the project was stopped. Github

Searching for ReMooD forks i found

Edward850's BananaSplit fork of Eternity

Yes i know about ReMooD and Edward850's BananaSplit Fork of Eternity.

While i was planning to make split-screen Doom a reality for Raspberry Pi, i did try to compile ReMooD and was succesful at some point making it work with some small bugs in X11. (this was in RetroPie 4.3 Jessie last year) and now i have already tried with compiling it recently which i failed. Since Doom Legacys latest version, the source port is more stable and it works great.

I have also managed to succesfully compile BananaSplit before and that source port is the fastest Doom source port that i have ever tried on my Raspberry Pi 3. That fork has 2 player split-screen but i could not get it to work, since it would just throw segfault error. Only singleplayer works. I even think it runs better than ZDoom according to my own opinion.

Rion

@tpo1990 How hard do you think it would be to implement @Protocultor 's Zdoom and Gampad Fully Working in to you Doom Legacy Split screen build?

The Eternity Engine sound really exciting!

Have you tried to contact Edward850 about BananaSplit Fork of Eternity?

tpo1990

@Rion Well it depends on how Doom Legacy sees the gamepad. Doom Legacy does in fact support joystick the same as ZDoom does and mapping some of the buttons on the gamepad in the options menu does seem to work, but im not sure if its possible to use the analog sticks in Doom Legacy.

Doom Legacy has its own configuration file named config.cfg. You could possibly manually map the correct joystick buttons by making changes into its configuration file. It might not be that hard to implement @Protocultor 's Zdoom gamepad solution.

You would be looking at the setcontrol variable for player 1. in the config.cfg file found in /opt/retropie/configs/ports/doom.
setcontrol2 is player 2.

My primary focus is on Doom Legacy, but i would like to also have a look into getting other Doom source ports to work as well.

tpo1990

So i managed to get a working scriptmodule for Zandronum source port to work in RetroPie and i have created a new repository for the purpose of testing out other Doom source ports, configuration and mods as well.

Check it out from this other thread: https://retropie.org.uk/forum/topic/22108/doom-development-repository

In the meanwhile the repository only contains Zandronum scriptmodule but will get many more at a later stage.

Use the command in terminal or CLI:

wget https://raw.githubusercontent.com/tpo1990/Doom-RPI/master/scriptmodules/zandronum.sh -P /home/pi/RetroPie-Setup/scriptmodules/ports/

Protocultor

@tpo1990 that's awesome! I just wanted to point out a couple of things:

I was missing mercurial and libssl-dev, but didn't realize until I checked out the logs. Maybe should be included in the dependencies?
Compilation also generates brightmaps.pk3 and skulltag_actors.pk3, files that don't end up in the target directory. Game still starts without them, but you should include them just in case.

Keep up the great work!

tpo1990

@Protocultor Yeah but one thing to take note of is that Zandronum will use its latest version from its bitbucket repository when getting installed by the scriptmodule and at that moment it is an 3.1 alpha version.

This version is not compatible with its latest stable version 3.0 that Windows users uses. We might get it to compile at the latest stable version at some time, but that will need some further insight.

I did notice that the Zandronum binary only requires the zandronum.pk3. Im thinking that the brightmaps.pk3 and the skulltag_actors.pk3 is some features that is included but not necessary for the port to run.

Thank you for testing out the Zandronum scriptmodule. I will update the scriptmodule with the missing dependencies and other pk3 files that the compilation generates.

tpo1990

Okay so i have now updated the Zandronum script to include mercurial and libssl-dev and make the target include brightmaps.pk3 and the skulltag_actors.pk3

RetroS3xual

@tpo1990 @Protocultor Wanted to let you know that I've tested this on Odroid XU4 RetroArena build and it's been working great. Specifically focused on using Brutal Doom as the test subject but I made the changes in various files based on @Protocultor 's changes from the ZDoom Gamepad thread (adding the menu button, changing button maps, etc.) and it works as intended.

Protocultor

@RetroS3xual thanks a lot for the feedback! Can you check out if the other changes I've added create some conflict on the Odroid?

https://github.com/protocultor/zdoom/commit/6b1fb6fef688d54de504644eb4b23e5d967c9f9d
https://github.com/protocultor/zdoom/commit/bce6214a6867709752981c6399d3eac15c4ec532

This is the full diff:
https://github.com/RetroPie/zdoom/compare/retropie...protocultor:retropie

tpo1990

@RetroS3xual Sounds great. Did you use Zandronum or ZDoom port on the Odroid and if so, what is the performance on it? :-)

RetroS3xual

@tpo1990 I used your script and added it to the "ports" script as RetroArena doesn't have an experimental package, but after I installed it through the setup script, everything worked as intended. I dove into the local repo after confirming it would launch and made the modifications from @Protocultor, recompiled, and played around with Brutal Doom. It performed fairly decently but I'd like to go back and make some actual notes as to what I experienced. After doing some reading about the differences between Zandronum and GZDoom, I moved on to try and find a GZDoom build that would work on Odroid. For GZDoom, I found that this repo https://github.com/drfrag666/gzdoom/tree/g3.3mgw could be compiled using these instructions https://zdoom.org/wiki/Compile_GZDoom_on_Linux#GZDoom_1.8.6 As always, I made the joypad modifications and was able to enjoy the Castlevania - Simon's Destiny mod with full audio and only slight video performance degradation. I went back and tried Brutal Doom with the accompanying soundtrack mod and both performed fairly well. I can provide my build steps and an assessment of the performance later today as I was scraping with Skyscraper at the time and I believe that affected the performance overall. Let me know the test cases you want as I've got both Odroid XU4 and RPi3 s to test with.

tpo1990

@RetroS3xual That is great news. Thank you for the feedback. I can not say for the Odroid, but Brutal Doom as i have experienced on the RPI3 with ZDoom from RetroPie repo needs to have turned off some of the graphical settings for it to run mostly without some lag. I believe its because of the particles from Brutal Doom that is quite heavy on the performance.

According to the compiling instructions that you found, that is for the older GZDoom 1.8.6 and not the latest version. Raspberry Pi can only use OpenGL ES and not OpenGL. If OpenGL is enabled on the source port it will run with lag on RPI and therefore disabling OpenGL would be preferred. I know this since i have tested it with another Doom source port called "Eternity Engine".

Is your build steps only for the Odroid or could it be used for the RPI as well?

RetroS3xual

@tpo1990 When I used ZDoom on the RPi, I experienced what you are describing. I used the build steps for 1.8.6 because I received error messages about calling other libraries and them not being present ("No such file or directory" in the stacktrace). Setting the compiler to version 5 in the instructions seemed to circumvent the issue. I know that I had to set "opengl es" to true for ZDoom but I will check all of my launch instructions and let you know. If I remember from my reading, the latest GZDoom utilizes OpenGL 3.3 but Odroid and RPi can only emulate up to OpenGL 2.0 via OpenGL ES (if this is inaccurate, let me know). Brutal Doom would load and play well on the Odroid until the fire effect had to be rendered. It severely lagged while on screen but seemed to be fine when at a distance. I have been busy this week, but will provide better details as soon as I can.

tpo1990

@RetroS3xual Thank you for research. Any help is appreciated. Yes i believe so i also read somewhere that it is only up to OpenGL 2.0 that the Raspberry Pi can accept. As long as running with OpenGL through OpenGL ES is slow, i would stay away from it and then only run ZDoom or any other source port with Software SDL renderer, since it runs best in that setting.

Maybe i should try compiling GZDoom 1.8.6 as you did. I can create a scriptmodule for RetroPie once we have something working. :-)

Solid One

@tpo1990 said in Doom Pi Project Need Advise:

I have also managed to succesfully compile BananaSplit before and that source port is the fastest Doom source port that i have ever tried on my Raspberry Pi 3. That fork has 2 player split-screen but i could not get it to work, since it would just throw segfault error. Only singleplayer works. I even think it runs better than ZDoom according to my own opinion.

Recently I tested Eternity BananaSplit on windows with my xbox360 controllers, to see how this sourceport handles Doom Splitscreen with controllers. When figuring out how to get it to work, I stumbled on this link, specifically in the line that says:

"Make sure your game is in GL2D in the video options. Splitscreen will abort if attempted in SDL software."

When reading that you got only segfault errors when trying to compile and run Eternity BananaSplit w/ splitscreen on your RPi3, I thought that maybe it crashed because you're trying to run it in SDL software mode. That being the case, maybe it would work if run on GL2D (OpenGL). What do you think?

I was surprised how Eternity BananaSplit has full controller support, with analog sensitivity for walking and aiming on both analog sticks, menu navigation without keyboard and even generic USB controllers, everything out of the box. And since it supports splitscreen up to 4 players, I believe it may be even better than Doom Legacy / ReMood. Having it on RPi would be really awesome!

tpo1990

@Solid-One I have already checked out that doomworld post a long time ago, thats where i learned about the Bananasplit fork of Eternity Engine. I did try out splitscreen once after i changed to GL2D in the options, but the performance of the game was too slow in order to keep a well running game.

If it wasn't for the slow performance and due to limit of only being able to do splitscreen mode, i would have already been using Bananasplit. But because of that Doom Legacy is a much better choice in regarding to get a smooth working splitscreen experience on our Raspberry Pi.

Maybe i could look into getting my hands on how to create a libretro port of Doom Legacy, but that would require more of my time.

Solid One

@tpo1990 Yes, I understand. And indeed Doom Legacy can render a much smoother splitscreen performance (it was originally developed for MS-DOS about 10~20 years ago). It even has multiplayer bots, and they are very decent for deathmatches.

On a different note, I read you guys are trying to compile Zandronum for RPi, but are having trouble compiling from the latest stable version (3.0), so you can't play online by using Zandronum + Doomseeker, right? Anyway, I think I just found a way of compiling latest stable version from source. Take a look here: https://wiki.zandronum.com/Compiling_Zandronum_on_Linux#Latest_stable_version

Basically, instead of compiling from latest alpha, you type the command below in order to find out which commit was used for compiling 3.0 release binaries:

cd ~/zandronum_build/zandronum &&
if [ "$(hg log -r 'max(tagged())' --template '{rev}\n')" -ge \
"$(hg log -l1 -k 'BUILD_ID_STR to release' --template '{rev}\n')" ]; then
hg identify -r 'max(tagged())'; else u="$(hg log -l1 -k 'BUILD_ID_STR to release' \
--template '{node|short}\n')"; echo "$u $(hg log -r $u --template '{desc}\n' |
sed -n 's/.*changed the version string to \(.*\)/\1/p')"; fi

Here's the result when you run that command after cloning the repository:

dd3c3b57023f ZA_3.0

Then I copied that hash above and searched for any commits containing it, and I found this commit:
https://bitbucket.org/ptitSeb/zandronum/commits/dd3c3b57023f64cda84f09ed13e4c03a4ad2b920

- changed the version string to 3.0
- changed BUILD_ID/BUILD_ID_STR to release

In other words, compiling Zandronum from that commit will give you the binaries for zandronum client 3.0.

And that's it. Try checking out all the instructions from the link above, and maybe you can finish the dependencies to get Zandronum working on RPi. And even play online through Doomseeker, which has hundreds of servers running Doom in a lot of different ways.

tpo1990

@Solid-One I'm quite sure that i already tried it but failed to get it to build to ver. 3.0. It would just build the alpha version instead. I might try it again. Thank you for your input.

Solid One

@tpo1990 If it fails to build, then I think I know the reason:
https://bitbucket.org/ptitSeb/zandronum/commits/121db9d6e8ec8bfa35672f8b1a63cf1d7e71289e

Fixed a compile problem on Raspbian Stretch.

The commit above is 10 commits after the one tagged as ZA_3.0 (the same from the link on my previous post), and was pulled in the same month as the 3.0 release. This commit basically change the file src/p_spec.cpp in order to change the type of a constant from char to SBYTE.

Assuming that was preventing Zandronum 3.0 stable to build, maybe this can work. However, it won't work if you simply clone the repository from that commit, since it'll change version from stable to alpha again, and then won't work for playing online.