Doom Pi Project Need Advise

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.

tpo1990

@Solid-One So it has to be changed to specific use that commit when trying to compile Zandronum and the solution to the Raspbian Stretch might just work. Let me give it a try and see what i can come up with.