Raspberry Pi vs Raspberry Pi 4 & PI 400

[DoomGater]

I did not know where to put this, so I opened up a new topic.
Please don't ban me !

I installed PRBOOM-PLUS and Chocolate-Doom out of the regular repositories

on a old Raspi Pi B+ and new Pi 4 & Pi 400. All PIs are running latest Raspberry OS (Buster-based).

But: Old Pi can run both doom ports without starting X-Server, Pi4 & 400 require 'startx' / desktop.

 

Why? and how can I run these ports on Pi4&400 without desktop?

Any help will be appreciated. 

 

 

[DoomGater]

Nobody??? The PI-guys don't have clue either. I HATE hardware-based software-problems as much as I hate
software-based hardware problems! AAArrgh...!

[Redneckerz]

If i were to wager a guess i'd say the difference in hardware makes a direct port not as straightforward as one thinks. Pi 4 is a significant upgrade over all other Pi's with its Cortex A7x cores.

[wrkq]

I didn't have a chance to touch the new raspi.

But this sounds like on the old pi you're running doom directly on the console framebuffer (fbdev).

And on the new one this is not possible so you must load up full graphics environment and access the GPU via DRI (or whatever's the current fashion) instead.

 

It may be that the new model is lacking the relevant drivers/features in the kernel (maybe disabled and possible to activate in custom kernel, maybe totally unavailable). Is the console looking "high res" or is it stuck in 80x25 characters mode?

 

I guess SDL on the new one could have been compiled without fb output support, but if you say its the same version of raspbian on old and new, it shouldn't be the case.

[DoomGater]

I never figured out the _exact_ details of Pi's video subsystem, but yes, it seems to be framebuffer in the configured mode. I am able to select resolution with 'raspi-config' and 
of course can use 'dpkg-reconfigure console-setup' to change font size. Funny thing is : Both installations(Pi / Pi4) came from the same image and share exactly the same sources.

As old-schooler I don't need or want always a desktop (mc, fim and mutt are my childhood's friends..) and prefer specially on those tiny computers to stay on the CLI...
But by the way: The raspi-guys don't have a clue, either :-)
 

[wrkq]

Mutt user since like 20 years too.

Sounds like it may be a bit more like "need to debug why SDL does not detect framebuffer" then.

Can you post output log from successful doom start on the pi2 and failed on the pi4?

Do you get different result if you configure the env var with

export SDL_VIDEODRIVER=directfb

before starting choco?

[DoomGater]

I guess I found something:
https://en.wikipedia.org/wiki/OpenGL_ES#Platform_usage
Old PI is openGL ES V2.0 compatible and new PI4/400 supports openGL ES V3.0.
Have to check if openGL ES V3 mandatorily requires X-Windows :-( 

Anyway, more testing required....I'll post as soon as I have new info....
 

 

 

 

 

[wrkq]

If you're testing with chocolate, opengl is not involved at all... it's all good old CPU based software renderer.

[DoomGater]

This is interesting. 
Choco Log says SDL:
 

Z_Init: Init zone memory allocation daemon. 
zone memory: 0xb484d008, 1000000 allocated for zone
Using /home/pi/.local/share/chocolate-doom/ for configuration and saves
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
saving config in /home/pi/.local/share/chocolate-doom/default.cfg
W_Init: Init WADfiles.
 adding /usr/share/games/doom/doom2.wad
===========================================================================
                         DOOM 2: Hell on Earth
===========================================================================
 Chocolate Doom is free software, covered by the GNU General Public
 License.  There is NO warranty; not even for MERCHANTABILITY or FITNESS
 FOR A PARTICULAR PURPOSE. You are welcome to change and distribute
 copies under certain conditions. See the source for more information.
===========================================================================
I_Init: Setting up machine state.
OPL_Init: Using driver 'SDL'.
NET_Init: Init network subsystem.
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon - ......................................
P_Init: Init Playloop state.
S_Init: Setting up sound.
D_CheckNetGame: Checking network game status.
startskill 2  deathmatch: 0  startmap: 1  startepisode: 1
player 1 of 1 (1 nodes)
Emulating the behavior of the 'Doom 1.9' executable.
HU_Init: Setting up heads up display.
ST_Init: Init status bar.

And CLI says:

Error creating window for video startup: Could not initialize EGL

 

[wrkq]

17 minutes ago, DoomGater said:

OPL_Init: Using driver 'SDL'.

This is in context of audio output.

 

I think no line mentioning use of SDL for video is printed (it's only option), although it might be smart to print what video output is used /by/ SDL if that information is available.

 

20 minutes ago, DoomGater said:

Could not initialize EGL

 

However about this.

From quick googling EGL is a OpenGL-ES "framebuffer like" output used on raw console without X11.

And on rpi there can be some mad stuff going on with SDL2 bugs, the type of GLES firmware (boot/config.txt) and kernel drivers compiled in.

 

But we're trying to run without GL at all.

 

I'm not in position to try myself rn - can you check output of

sdl-config

sdl-config --version

sdl-config --static-libs

and let me know if any of them prints the list of video drivers compiled into SDL?

 

Can you try running

SDL_VIDEODRIVER=fbcon ./chocolate-doom (args here)

SDL_VIDEODRIVER=directfb ./chocolate-doom (args here)

and see if you get any difference in output?

 

Also take a look here.

https://stackoverflow.com/questions/57672568/sdl2-on-raspberry-pi-without-x

It's older and about pi3 but with similar EGL errors.

The top-answer includes a small test C program to enumerate the drivers and showed that you get different results with and without SDL_VIDEO_EGL_DRIVER= set.

So maybe something here would help you (e.g. try to force videodriver to KMSDRM and renderdriver to software, but KMSDRM may require loading different stuff with raspi-config...)

[fabian]

1 hour ago, wrkq said:

If you're testing with chocolate, opengl is not involved at all... it's all good old CPU based software renderer.

Sorry, but you are wrong here. Choco does very well use GL, or whatever SDL chooses as a renderer, to scale its framebuffer content to screen. 

Edited December 8, 2020 by fabian

[wrkq]

1 hour ago, fabian said:

Sorry, but you are wrong here. Choco does very well use GL, or whatever SDL chooses as a renderer, to scale its framebuffer content to screen.  

 

I honestly didn't know that until @DoomGater posted the error log and I started to digging further.

But then allow me to ask something. Not arguing, I want to be sure I have it clear for the future.

Does choco actively/deliberately asks for GL in any way, or is this, as you actually phrased it, "whatever SDL chooses" so kinda SDL implementation detail?

 

That's how I thought after seeing the log, that Choco just sends pixels to SDL and all the trouble DG has here is "between SDL and the OS", because it tries to use EGL (and fails for whatever reason) instead of going plain software fbdev?

[DoomGater]

Ok, here we go. sdl-configure was not available by default, I had to install libsdl1.2-dev  manually.
It's V. 1.215 and sdl-config --static-libs gives:
"-L/usr/lib/arm-linux-gnueabihf -lSDL -lpthread -lm -ldl -lasound -lm -ldl -lpthread -lpulse-simple -lpulse -lX11 -lXext -lXrandr -lXrender -L/opt/vc/lib -lbcm_host -lvcos -lvchiq_arm -L/usr/lib/arm-linux-gnueabihf -lcaca -lpthread"

SDL_VIDEODRIVER fbcon / directfb does not make any difference---"Could not initialize EGL"...

 

3 hours ago, wrkq said:

And on rpi there can be some mad stuff going on with SDL2 bugs, the type of GLES firmware (boot/config.txt) and kernel drivers compiled in.

I assume that's one of the main reasons. Above that it is still OpenGL ES2 vs OpenGL ES3. 

I guess this will turn into a strong demand for vulkan from the CLI... :-)
https://www.raspberrypi.org/blog/vulkan-raspberry-pi-first-triangle/

Edited December 8, 2020 by DoomGater
add some results

[wrkq]

Ffff, forgot about debian fun. The tool we're looking for is probably sdl2-config then or similar.

I'll stop wasting y'alls time then - maybe this driver test program for sdl2 (from the stackoverflow post) will give you some hints, maybe not, but without the hardware I really don't want to send you chasing more rabbits.

[DoomGater]

6 minutes ago, wrkq said:

Ffff, forgot about debian fun. The tool we're looking for is probably sdl2-config then or similar.

I'll stop wasting y'alls time then - maybe this driver test program for sdl2 (from the stackoverflow post) will give you some hints, maybe not, but without the hardware I really don't want to send you chasing more rabbits.

:-)  I can understand that completely. Anyway thanks a lot for investing your time and brain.  When/If I 'll find something, I'll post an update!
Thank You !

 

[fabian]

2 hours ago, wrkq said:

Does choco actively/deliberately asks for GL in any way, or is this, as you actually phrased it, "whatever SDL chooses" so kinda SDL implementation detail?

 

The details are here:

 

https://github.com/chocolate-doom/chocolate-doom/blob/0b76cbbe94a8a4b7562e3f95dfc00c1110b707a4/src/i_video.c#L1250

 

Basically, we ask SDL for a renderer that supports VSync and if that fails we fall back to a software renderer.

 

1 hour ago, DoomGater said:

It's V. 1.215 and sdl-config --static-libs gives:

 

sdl-config is deprecated, that was SDL1.x times. Nowadays the cool kids are using "pkg-config SDL2" with the same parameters.

[DoomGater]

I'ts a shame, that the cool kids nowadays are not getting any useful results either...

 

Let's see where Raspian OS is taking this, PI4's graphic driver still is a major construction site,
but I am afraid that more and more they will take away Linux' ability do do things from the command line.

 

[DoomGater]

UPDATE: concerning the performance: DOOM on the the old PI3 (4x1200MHz, 1GB RAM)
is quite a bit faster than on the PI4 (4x1500MHz, 4GB RAM). X-Windows takes its toll.. 

UPDATE2: 
Even the Pi2 with its 4x900MHz does outperform the PI4 doom-wise.
Quite understandable, because performance-wise Pi2 it is closer to the Pi3 than Pi 3 to Pi4....

So I really do not see an advantage here for PI4/400's new drivers/architecture.
But soon somebody will tell, optimization is not done yet and the drivers
still are beta quality and who the f..(ramebuffer?) cares, doom is such an old game.
Now it is much easier to develop shiny new games and we can make more money
selling unoptimized, but highly portable crap for all platforms to the kiddies.
Sorry, for overreacting, but we've been there before.

 

 

 

Edited December 10, 2020 by DoomGater

[fabian]

10 minutes ago, DoomGater said:

UPDATE: concerning the performance: DOOM on the the old PI3 (4x1200MHz, 1GB RAM)
is quite a bit faster than on the PI4 (4x1500MHz, 4GB RAM). X-Windows takes its toll.. 

 

More probably, EGL-accelerated scaling vs. software scaling.