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

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

Re: Building GZDOOM without OPENGL

Post by dpJudas » Mon Jan 30, 2017 4:02

QZDoom has a newer framebuffer backend for the software renderer that uses OpenGL hardware acceleration for its 2D (vid_hw2d), just like the Direct3D 9 target does on Windows. It therefore doesn't use the old SDL GLES2 backend you're referring to. My changes was about adding native GLES2 support to that version. You can see the visual difference by bringing down the console - in QZDoom it does a nice translucent alpha blending, while in ZDoom it does not.

Because the new framebuffer backend shares OpenGL initialization code with the main GZDoom OpenGL renderer, my support indirectly added about half of what is needed to allow GZDoom itself to run with OpenGL ES. What may be missing is some minor adjustments to the shaders, and then some solution to scene textures that aren't power-of-two.

About LLVM, yes, you have to build and install LLVM first. Sadly you can't use the distro packages as they seem to be broken. I'm planning on allowing the build to function without them, but my CMake skills are so poor that I haven't been able to stomach the thought of trying to change this yet.

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

Re: Building GZDOOM without OPENGL

Post by vanfanel » Thu Mar 30, 2017 9:50

@dpJudas: Any news on building QZDoom without LLVM support, please? I have found some issues to set it up on the Pi.

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

Re: Building GZDOOM without OPENGL

Post by dpJudas » Thu Mar 30, 2017 9:55

vanfanel wrote:
Thu Mar 30, 2017 9:50
@dpJudas: Any news on building QZDoom without LLVM support, please? I have found some issues to set it up on the Pi.
QZDoom doesn't use LLVM anymore. You should be able to compile the master branch on the Pi without problems.

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

Re: Building GZDOOM without OPENGL

Post by Rachael » Thu Mar 30, 2017 23:01

Providing, of course, I hadn't yet downstreamed a commit that broke GCC.

Speaking of which - lately I've been a little more selective about what I downstream, so QZDoom may compile from master more often than GZDoom does. Just note that truecolor and dynamic lights run really slow, even with the maximum optimizations - they'll have to be rewritten with intrinsics but I probably won't do that until I am convinced there's more than 10 people that use it.
Spoiler: Zen Sarcasm

_mental_
Developer
Developer
Posts: 256
Joined: Sun Aug 07, 2011 13:36

Re: Building GZDOOM without OPENGL

Post by _mental_ » Fri Mar 31, 2017 15:58

With continuous integration active it's very easy to check compilation status for those who build from sources: just look at commits page on GitHub.
If you see green V near commit message then everything is OK, if there is red X then something went wrong. Continuous integration platforms themselves might fail too although they show actual status most of the time.
Success/failure sing is clickable and contains links to details pages.

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

Re: Building GZDOOM without OPENGL

Post by Rachael » Fri Mar 31, 2017 19:34

Yeah I've been watching those. I try to usually only pull the commits that check okay. They have no ARM checks, but most of the time as long as no one plays with the software renderer drawers or introduces intrinsics elsewhere in the code ARM compiles just fine.
Spoiler: Zen Sarcasm

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

Re: Building GZDOOM without OPENGL

Post by vanfanel » Sun Apr 02, 2017 0:17

I got QZDoom to build on the Pi at last, no LLVM involved , thanks! :)
Now, if I bring on the console, it's the same as in ZDOOM: no transparency to be seen.
I'd swear I saw a menu to change renderer among the options but I can't see it anymore...
Also, trying to change vid_renderer=0 to 1 causes a crash. No GLES support still?

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

Re: Building GZDOOM without OPENGL

Post by Rachael » Mon Apr 03, 2017 0:44

Still no full GLES support.

You can try vid_glswfb to enable the (non)accelerated OpenGL software framebuffer, and use "gl_es" to switch that mode between on and off. If it actually works for you - more power to you, it always crashed for me.
Spoiler: Zen Sarcasm

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

Re: Building GZDOOM without OPENGL

Post by vanfanel » Mon Apr 03, 2017 10:23

@Rachael: it crashes here, too.
Regarding GLES support, which port should I watch: QZDoom or GZDoom?

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

Re: Building GZDOOM without OPENGL

Post by dpJudas » Mon Apr 03, 2017 14:20

None of the ports have finished GLES support. There is the gl_es switch that Rachael mentions, but for some reason it crashes with an unaligned memory access error. I need a call stack to be able to try fix that.

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

Re: Building GZDOOM without OPENGL

Post by vanfanel » Tue Apr 04, 2017 14:03

@dpJudas: You mean a simple gdb "bt" after the crash, right? Do you need anything else I can provide?

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

Re: Building GZDOOM without OPENGL

Post by Rachael » Tue Apr 04, 2017 14:21

As long as it shows what functions crashed, hopefully, even better - along with what the variables they were using were set at - that would be extremely helpful.
Spoiler: Zen Sarcasm

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

Re: Building GZDOOM without OPENGL

Post by vanfanel » Wed Apr 05, 2017 10:46

@Rachel: I think there's some problem with CMakelists.txt, because -DCMAKE_BUILD_TYPE=Debug is simply ignored.
I need to build a debug version if I am to provide reliable debug information...

To be precisse, it's not being ignored, but flags are added over non-debug flags, resulting in compilation lines like this:

Code: Select all

cd /home/pi/src/qzdoom/b3/dumb && /usr/bin/cc  -DNEED_ITOA=1 -ffp-contract=off -Wall -Wno-pointer-sign -Wno-uninitialized -Wno-unused-but-set-variable -ffast-math -ffp-contract=fast -O2 -DNDEBUG  -D_DEBUG -DDEBUGMODE=1 -I/home/pi/src/qzdoom/dumb/include    -o CMakeFiles/dumb.dir/src/core/duhtag.c.o   -c /home/pi/src/qzdoom/dumb/src/core/duhtag.c
Note the simultaneous "-O2 -DNDEBUG" and "-D_DEBUG -DDEBUGMODE=1" flags, which does not seem like a good idea in order to get reliable debugging.
Last edited by vanfanel on Wed Apr 05, 2017 10:58, edited 1 time in total.

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

Re: Building GZDOOM without OPENGL

Post by Rachael » Wed Apr 05, 2017 10:57

_mental_ would know more about that than I do, I think.
Spoiler: Zen Sarcasm

_mental_
Developer
Developer
Posts: 256
Joined: Sun Aug 07, 2011 13:36

Re: Building GZDOOM without OPENGL

Post by _mental_ » Wed Apr 05, 2017 13:37

The Debug build option isn't ignored. Several libraries are forced to build in Release configuration.
Look for make_release_only() macro in CMake files.
If it causes some troubles to you, comment body of this macro to make fully de-optimized build.

Locked

Return to “Technical Support”