Building GZDOOM without OPENGL

Something not working in GZDoom that's not a bug? Is the display a bit quirky and unexpected? Post here.

Moderator: Graf Zahl

vanfanel
Posts: 35
Joined: Mon Mar 12, 2012 19:31

Re: Building GZDOOM without OPENGL

Post by vanfanel »

@dpJudas:
Now GLES2 seems to be detected... but nothing comes up on the Pi screen. GDB stalls, there's no way for me to exit it and go back to bash:

Code: Select all

pi@raspberrypi:~/doom $ ./doom
GNU gdb (Raspbian 7.7.1+dfsg-5+rpi1) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./qzdoom...done.
(gdb) set print thread-events off
(gdb) r
Starting program: /home/pi/doom/qzdoom -iwad doomu.wad
Dwarf Error: wrong version in compilation unit header (is -25251, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/02/4da9b35ba4e86bf23715795948d86728d8a39d.debug]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Dwarf Error: wrong version in compilation unit header (is -24386, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/4d/459747ca3ce1a8adf08cdbb41e2c9bd5602990.debug]
Dwarf Error: wrong version in compilation unit header (is 9667, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/90/57a5b1f2a4bbdcd06303287ce89e4ccf5f1ff7.debug]
warning: File "/usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
	add-auto-load-safe-path /usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.22-gdb.py
line to your configuration file "/home/pi/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/pi/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
Dwarf Error: wrong version in compilation unit header (is -27098, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/e5/f4e3d59b5ec692e4080943a9e5f52715dbe939.debug]
Dwarf Error: wrong version in compilation unit header (is 25537, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/25/b79f1158416df418745ba9f322d5c68daf18e6.debug]
QZDoom q1.3pre-1662-g00531cd - 2017-04-09 11:53:40 -0400 - SDL version
Compiled on Apr  7 2017

M_LoadDefaults: Load system defaults.
Dwarf Error: wrong version in compilation unit header (is 6565, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/c5/15c3b091677587381f57155ad7ac3707c71dce.debug]
Dwarf Error: wrong version in compilation unit header (is 25481, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/86/b6212d2d7578042b59581378f58b49f7fdf30f.debug]
Dwarf Error: wrong version in compilation unit header (is 942, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/2f/54912a1710ee0427b32aee981e5f59459dadf2.debug]
Dwarf Error: wrong version in compilation unit header (is -16159, should be 2, 3, or 4) [in module /usr/lib/debug/.build-id/2c/5368760b1e037fe7746f1a9adc47e4dc70adf8.debug]
W_Init: Init WADfiles.
 adding /home/pi/doom/qzdoom.pk3, 711 lumps
 adding doomu.wad, 2306 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 23209.46 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
GL_VENDOR: Broadcom
GL_RENDERER: VideoCore IV HW
GL_VERSION: OpenGL ES 2.0 (Compatibility profile)
GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 1.00

Max. texture size: 2048
Max. texture units: 8
Max. varying: 8
Max. uniform block size: 8
Uniform block alignment: 8
^C

^Z

^C
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Building GZDOOM without OPENGL

Post by Rachael »

That sounds like it could be a driver or kernel issue. Is there any way to run a debugger on it to figure out at what point it is freezing?
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Building GZDOOM without OPENGL

Post by dpJudas »

Honestly, I think we pretty much reached the stage where it requires a developer with such a setup to further diagnose and fix any remaining issues. It was worth a try adding it remotely like I did, but that approach did not work out.
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Building GZDOOM without OPENGL

Post by Rachael »

Hmm - I had a blank screen on my AMD Linux system as well when trying OpenGL ES. I wonder if it is the same issue? That would make it much easier to work with - having an actual ES implementation that exhibits the same problem on a non-RPi system.

Also, might it be worth bringing Beloko into the fold on this? Surely he'd be a lot happier having native OpenGL ES code to work with upstream because that would be less merge conflicts for him downstream later on when updating.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Building GZDOOM without OPENGL

Post by dpJudas »

It could be the same issue with regard to the black screen, but it would not explain why the console stops being responsive. Unfortunately I only have a Nvidia card, so I can't debug why you got a black screen either.

About Beloko, I don't know why he chose to use some kind of emulation layer rather than supporting OpenGL ES directly. As far as I know, his version relies solely on the fixed function path (OpenGL 1). At least for glswfb it really needs shaders as it is based on the Direct3D 9 backend, which only supported shader rendering.

At the end of the day this needs a developer with the proper hardware. While I theoretically *could* try get something done via remote desktops or emulators it has gotten so boring at this point that I'd rather do real paid work than this. :)
vanfanel
Posts: 35
Joined: Mon Mar 12, 2012 19:31

Re: Building GZDOOM without OPENGL

Post by vanfanel »

I am willing to donate the hardware if it's needed: I have several Pi 2 around here, so I could send you one. How does that sound?
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Building GZDOOM without OPENGL

Post by Rachael »

I hate to say this but I don't think Pi 2's will even be useful right now. And the cost to ship those might well be more than they're worth new, anyway.

It'd be better to simply start from scratch and get a new Pi 3 - or hopefully a Pi 4 if they're coming out soon.

Additionally, dpJudas did not quote that as being the problem - the problem is he doesn't even want to work with it. Pi's are exceptionally slow systems - they work for what they do, but any laptop 10 years old or newer is much better and easier to work with. In my personal experience, even a desktop operating system (Ubuntu Mate) is a bit taxing on the thing.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Building GZDOOM without OPENGL

Post by dpJudas »

Yes, thanks for the offer vanfanel, but it is not really an economic issue for me. I had just hoped that I could get the OpenGL ES support working without putting any real substantial effort towards it.
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Building GZDOOM without OPENGL

Post by Rachael »

Apparently you got GLES 3 working, just not 2 that Pi actually uses. >_<
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Building GZDOOM without OPENGL

Post by Rachael »

This is just a courtesy note that QZDoom has now officially taken on a different project. It will likely be better to pull from GZDoom's repository, now.
vanfanel
Posts: 35
Joined: Mon Mar 12, 2012 19:31

Re: Building GZDOOM without OPENGL

Post by vanfanel »

@Rachael: So the problem is that QZDoom needs GLES3?
Are you also saying I should try GZDoom instead of QZDoom for GLES2 support?
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Building GZDOOM without OPENGL

Post by Rachael »

No, QZDoom still pulls from GZDoom. QZDoom just isn't focused on the renderers anymore, now. It's moving onto netcode. GZDoom has everything already, anyway.
vanfanel
Posts: 35
Joined: Mon Mar 12, 2012 19:31

Re: Building GZDOOM without OPENGL

Post by vanfanel »

@Rachael: Sorry, I did not understand you well. When you say GZDoom has "everything already, anyway", do you mean it has working GLES support? Or that it is going to have it?
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Building GZDOOM without OPENGL

Post by Rachael »

Yes - everything from QZDoom's renderers have been merged into GZDoom now. GZDoom 3.0 is due out by next month and will have QZDoom's renderer features built in.
vanfanel
Posts: 35
Joined: Mon Mar 12, 2012 19:31

Re: Building GZDOOM without OPENGL

Post by vanfanel »

@Rachael: What GLES version does GZDoom support? GLES1 and GLES2 is what the Pi supports. Any hopes for that?
Does it init the context using SDL2 or does it mangle with X11/whatever directly? GLES1 and GLES2 on the Pi via SDL2 context should work: GLES1/2 tests work.
Locked

Return to “Technical Support”