Doom Pi Project Need Advise

RetroFreak89

@stevejp1978 i believe if you use zdoom port which is on retropie it has that same hd textures in settings and works fine.. but zdoom is outdated so i want to avoid it

RetroFreak89

@tpo1990 nicee i have no idea how to compile im looking for a source port that gives best performance on the pi and that plays boom wads what do you recommand??
I only know how to get zdoom and prboom working which bot are outdated engines :(
I think my best bet might be prboom plus,crispy/chocolate or legacy or mayb zandronum?? But how do you compile so i can try itsorry huge noob here maybe you can paste the commands so i can paste it lol im that big of a noob when it comes to these commands

RetroFreak89

Anyone here that play doom wads? Whats your port of choice?

tpo1990

@RetroFreak89 The Doom Legacy port is available for you to install as a scriptmodule, just like you would install zdoom from the RetroPie setup. I have made it so that it is easy to install just download the scriptmodule from my github page.

You could try Zandronum or GZDoom source port, but that will require you to compile it by your self. I have earlier been successful at compiling both these source ports. From what i can tell, Zandronum seems like the online mulitplayer port of choice and GZDoom seems like an updated ZDoom source port, which its development has picked up after Zdoom has stopped development.

These are all the ZDoom variants out there:
ZDoom: Old doom source port. Outdated and . (Used for RetroPie project)
GZDoom: Primary doom source port. Enhanced OpenGL (Still in development)
QZDoom: Test source port for implementing new features into its primary source port(For testing purposes)

Other variant:
Zandronum: Not Zdoom but previously known as the online multiplayer source port Skulltag.

For what you seem to be looking for i would think that GZDoom will fit your needs since that one is built on ZDoom and improving. It should also be mentionen that GZDoom can use OpenGL as well. If you want i could probably built a working scriptmodule for testing out on our RetroPie.

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.