Building GZDOOM without OPENGL
Moderator: Graf Zahl
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Building GZDOOM without OPENGL
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.
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.
-
- Posts: 35
- Joined: Mon Mar 12, 2012 19:31
Re: Building GZDOOM without OPENGL
@dpJudas: Any news on building QZDoom without LLVM support, please? I have found some issues to set it up on the Pi.
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
- Rachael
- Developer
- Posts: 3646
- Joined: Sat May 13, 2006 10:30
Re: Building GZDOOM without OPENGL
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.
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.
-
- Developer
- Posts: 259
- Joined: Sun Aug 07, 2011 13:36
Re: Building GZDOOM without OPENGL
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.
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.
- Rachael
- Developer
- Posts: 3646
- Joined: Sat May 13, 2006 10:30
Re: Building GZDOOM without OPENGL
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.
-
- Posts: 35
- Joined: Mon Mar 12, 2012 19:31
Re: Building GZDOOM without OPENGL
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?
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?
- Rachael
- Developer
- Posts: 3646
- Joined: Sat May 13, 2006 10:30
Re: Building GZDOOM without OPENGL
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.
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.
-
- Posts: 35
- Joined: Mon Mar 12, 2012 19:31
Re: Building GZDOOM without OPENGL
@Rachael: it crashes here, too.
Regarding GLES support, which port should I watch: QZDoom or GZDoom?
Regarding GLES support, which port should I watch: QZDoom or GZDoom?
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Building GZDOOM without OPENGL
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.
-
- Posts: 35
- Joined: Mon Mar 12, 2012 19:31
Re: Building GZDOOM without OPENGL
@dpJudas: You mean a simple gdb "bt" after the crash, right? Do you need anything else I can provide?
- Rachael
- Developer
- Posts: 3646
- Joined: Sat May 13, 2006 10:30
Re: Building GZDOOM without OPENGL
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.
-
- Posts: 35
- Joined: Mon Mar 12, 2012 19:31
Re: Building GZDOOM without OPENGL
@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:
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.
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
Last edited by vanfanel on Wed Apr 05, 2017 10:58, edited 1 time in total.
- Rachael
- Developer
- Posts: 3646
- Joined: Sat May 13, 2006 10:30
Re: Building GZDOOM without OPENGL
_mental_ would know more about that than I do, I think.
-
- Developer
- Posts: 259
- Joined: Sun Aug 07, 2011 13:36
Re: Building GZDOOM without OPENGL
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.
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.