Doom Pi Project Need Advise

tpo1990

@stevejp1978 It depends on which Doom Experience you want and what kind of gameplay you like.

Chocolatedoom is probably the best source port to experience Vanilla Doom.
Zandronum is probably the best online mulitplayer port to use.
GZDoom or ZDoom is probably the best Doom source port that supports boom and custom compatible wads.

I would say that all the doom source ports has their advantages to its own in regarding what kind of features that they offer.

Protocultor

@tpo1990 do you remember how well (or badly) GZDoom ran on your Raspi?
I'm interested about trying it. Can you give me some tips about how to compile it for a 3B+? I barely know how to compile ZDoom and CMake is currently my kryptonite. Any info you can give me is useful.

tpo1990

@Protocultor From what i can remember: The first time i tried to compile it i had some troubles. You need to make sure that you install all needed dependencies/packages first before downloading and compiling from source. When compiling from source, it is necessary to know which version to compile since there is an stable, alpha and a old GZDoom 1.8.6.

After compilation i did change some video settings to make it run as good as ZDoom in the game. GZDoom ran pretty well.

Since it is just an enhanced ZDoom i think we should be able to run it on our Raspi. I could probably create a working scriptmodule as well for RetroPie just like my other work.

I used the compile documentation from the official link: https://zdoom.org/wiki/Compile_GZDoom_on_Linux

Protocultor

@tpo1990 many thanks for all the info!
I'll try my luck with a newer version of GZDoom, since 1.8.6 is pretty equivalent to what we already have on ZDoom, but it's always good to know that it's possible :) . Cheers!

RetroFreak89

@tpo1990 yes plz do so im so confused on this compiling thing not sure how it all works yet..
After downloading the file from github what do i do with it??
Sorry kind of a big noob here

Protocultor

Managed to compile different versions of GZDoom, but none of them ran.
4.0.0 says I don't have OpenGL 3.3 (duh)
3.4.0 says "failed to load OpenGL functions"; I tried it after I found out it was the last supporting OGL 2.0
3.1.0 just crashed, and I couldn't get any clue from the log.
Tried them with different drivers in raspi-config -> advanced, but nothing came out. Maybe it's my Pi (updated constantly), but I'll let someone else try to make it work; I'll get back to old trusty ZDoom.

edmaul69

@Protocultor aint nothing wrong with trusty old zdoom. I have like 65 games running on it so i aint complaining.

tpo1990

@RetroFreak89

After downloading the Doom Legacy scriptmodule, it needs to be placed in /home/pi/RetroPie-Setup/scriptmodules/ports/
and then you should be able to install Doom Legacy the same way as you would install ZDoom from RetroPie Setup.

No problem, i will help out as much as i can.

tpo1990

@Protocultor Where did you try run the GZDoom binary?

Was it in CLI/Emulationstation or in X11 Window/Raspbian desktop?

Now that i think of it, it could be that i was able to run GZDoom in Raspbian Desktop which uses the X11 Window and not in Emulationstation.

When you try to compile from source, sometimes it will be compiled with support for the framebuffer which CLI/Emulationstation uses or not. It could be both Framebuffer/X11 or it could be one of them. Also you might need to change some variables in the makefile in order to make the GZDoom binary able to use Framebuffer or SDL as what ZDoom uses.

Framebuffer: Is what Emulationstation uses when using runcommand script.
X11 Window: Is what Raspbian Desktop uses, when using applications in the desktop environment.

I will try to compile GZDoom on my test Raspi SD card and see if i can get it to work again.

mitu

Might be worth trying to run with +set gl_es 1 to force the GLES SDL renderer for the framebuffer version (see this commit. Otherwise, OpenGL means X11 must be used.

tpo1990

@mitu I might look into that when trying to compile GZDoom again on my test Raspi. Thank you Mitu.

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.