Doom Pi Project Need Advise

Protocultor

@tpo1990 now I feel dumb, completely forgot about trying it under X11. Tried it always in CLI, because I want it under Emustation.
I'm not good with (c)make, and the only option I found was NO_GTK which I enabled (thank gods for ccmake); I assumed it was enough, but didn't make a difference except for the style of the windows it showed when crashed.
Tested it under desktop and "kind of wanted to start" even creating a window and giving me the creepy sound when Doom 1 starts, but crashed after that.

+set gl_es 1 did have an effect, 3.4.0 at least showed that it recognized GLES before crashing. Without it, it just exits saying "no OpenGL functions". That's under both CLI and PIXEL.

If you can make it run under framebuffer, I'd be super grateful.

mitu

Doesn't seem to work under the framebuffer - i.e. via GL ES. It crashes with the same message:

/gzdoom -debug +set gl_es true
GZDoom g4.1pre-399-g15d2b4779  - SDL version

SDL EVENT: SDL_JOYDEVICEADDED (timestamp=76 which=0)
M_LoadDefaults: Load system defaults.
W_Init: Init WADfiles.
 adding /home/pi/gzdoom/release/gzdoom.pk3, 621 lumps
 adding /home/pi/gzdoom/release/zd_extra.pk3, 1520 lumps
 adding ./Doom1.WAD, 1264 lumps
I_Init: Setting up machine state.
I_InitSound: Initializing OpenAL
  Opened device ALSA Default
  EFX enabled
V_Init: allocate screen.
S_Init: Setting up sound.
ST_Init: Init startup screen.
Checking cmd-line parameters...
S_InitData: Load sound definitions.
G_ParseMapInfo: Load map definitions.
Texman.Init: Init texture manager.
ParseTeamInfo: Load team definitions.
LoadActors: Load actor definitions.
script parsing took 2326.39 ms
R_Init: Init Doom refresh subsystem.
DecalLibrary: Load decals.
M_Init: Init menus.
P_Init: Init Playloop state.
ParseSBarInfo: Loading custom status bar definition.
D_CheckNetGame: Checking network game status.
player 1 of 1 (1 nodes)
Using video driver RPI
SDL EVENT: SDL_WINDOWEVENT (timestamp=11627 windowid=1 event=SDL_WINDOWEVENT_ENTER data1=0 data2=0)
SDL EVENT: SDL_WINDOWEVENT (timestamp=11630 windowid=1 event=SDL_WINDOWEVENT_FOCUS_GAINED data1=0 data2=0)
SDL EVENT: SDL_WINDOWEVENT (timestamp=11630 windowid=1 event=SDL_WINDOWEVENT_SIZE_CHANGED data1=1920 data2=1080)
SDL EVENT: SDL_WINDOWEVENT (timestamp=11630 windowid=1 event=SDL_WINDOWEVENT_SIZE_CHANGED data1=1920 data2=1080)
SDL EVENT: SDL_WINDOWEVENT (timestamp=11630 windowid=1 event=SDL_WINDOWEVENT_SHOWN data1=0 data2=0)
Unsupported OpenGL version.
At least OpenGL 3.3 is required to run GZDoom.
For older versions of OpenGL please download the vintage build of GZDoom.

In all fairness, I'm using the latest git (4.1).
I have stumbled upon an previous topic on the GZDoom which might indicate that GLES3 might be needed (https://forum.zdoom.org/viewtopic.php?f=50&t=60873).
I guess I'll give the legacy (3.x) branch a try.

tpo1990

Now that it comes to mind my, it might have been Zandronum that i was successful at compiling earlier. It certainly works both in X11 and Framebuffer. I was able to compile Zandronum by following the french site framboisepi.fr, but unfortunately it builds an 3.1 alpha version instead of the latest primary version 3.0 in which Windows users uses. I will look into making it build the latest stable version 3.0.

I also came across a reddit topic stating that GZDoom might not be able to work on our RPI due to either poor OpenGL support or performance. Reddit link

Here is another website where someone did manage to change some OpenGL variables in the source files of GZDoom so that it does not rely on OpenGL when compiling. (This might be worth checking out) DRDTeam link

I think our best is Zandronum instead of GZDoom. Zandronum seems to look identical to ZDoom and its other versions but with focus on enhancing multiplayer. It is also one of the following ports that Doomseeker uses to launch into playing online. (Doomseeker is a online multiplayer launcher gui) Zandronum might just be a good alternative over using ZDoom.

mitu

@tpo1990 said in Doom Pi Project Need Advise:

Here is another website where someone did manage to change some OpenGL variables in the source files of GZDoom so that it does not rely on OpenGL when compiling. (This might be worth checking out) DRDTeam link

Thanks for digging this. From what I gather in that topic is that GLES3 is still required using GL ES (i.e. not using OpenGL). That might work for the systems what support it (like the Odroid XU4 or N2), but for the Raspberry PI the limit is GLES2.

tpo1990

@mitu said in Doom Pi Project Need Advise:

@tpo1990 said in Doom Pi Project Need Advise:

Here is another website where someone did manage to change some OpenGL variables in the source files of GZDoom so that it does not rely on OpenGL when compiling. (This might be worth checking out) DRDTeam link

Thanks for digging this. From what I gather in that topic is that GLES3 is still required using GL ES (i.e. not using OpenGL). That might work for the systems what support it (like the Odroid XU4 or N2), but for the Raspberry PI the limit is GLES2.

It might seems that we have a reached a hardware limit for our Raspberry Pi, which i therefore think that Zandronum would be our best bet to get working. I did also managed to get Doomseeker working as well in X11 and i could see online servers but unfortunately they were using Zandronum v3.0. If we could get that working as well it would make Online multiplayer in Doom a reality on our Raspberry Pi.

I tried yesterday with compiling QZDoom which is ZDoom's test base and it also asks for OpenGL when trying to launch the binary just like GZDoom does.

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