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 » Sun Apr 09, 2017 20:07

@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: 3617
Joined: Sat May 13, 2006 10:30

Re: Building GZDOOM without OPENGL

Post by Rachael » Mon Apr 10, 2017 1:46

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?
Spoiler: Zen Sarcasm

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Building GZDOOM without OPENGL

Post by dpJudas » Mon Apr 10, 2017 1:57

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: 3617
Joined: Sat May 13, 2006 10:30

Re: Building GZDOOM without OPENGL

Post by Rachael » Mon Apr 10, 2017 2:01

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.
Spoiler: Zen Sarcasm

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Building GZDOOM without OPENGL

Post by dpJudas » Mon Apr 10, 2017 2:34

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 » Mon Apr 10, 2017 8:53

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: 3617
Joined: Sat May 13, 2006 10:30

Re: Building GZDOOM without OPENGL

Post by Rachael » Mon Apr 10, 2017 16:24

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.
Spoiler: Zen Sarcasm

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Building GZDOOM without OPENGL

Post by dpJudas » Mon Apr 10, 2017 17:20

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: 3617
Joined: Sat May 13, 2006 10:30

Re: Building GZDOOM without OPENGL

Post by Rachael » Tue Apr 11, 2017 17:06

Apparently you got GLES 3 working, just not 2 that Pi actually uses. >_<
Spoiler: Zen Sarcasm

User avatar
Rachael
Developer
Developer
Posts: 3617
Joined: Sat May 13, 2006 10:30

Re: Building GZDOOM without OPENGL

Post by Rachael » Wed Apr 12, 2017 7:47

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.
Spoiler: Zen Sarcasm

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

Re: Building GZDOOM without OPENGL

Post by vanfanel » Wed Apr 12, 2017 9:37

@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: 3617
Joined: Sat May 13, 2006 10:30

Re: Building GZDOOM without OPENGL

Post by Rachael » Wed Apr 12, 2017 12:09

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.
Spoiler: Zen Sarcasm

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

Re: Building GZDOOM without OPENGL

Post by vanfanel » Tue Apr 18, 2017 16:05

@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: 3617
Joined: Sat May 13, 2006 10:30

Re: Building GZDOOM without OPENGL

Post by Rachael » Tue Apr 18, 2017 16:31

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.
Spoiler: Zen Sarcasm

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

Re: Building GZDOOM without OPENGL

Post by vanfanel » Tue Apr 18, 2017 20:41

@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”