Building GZDOOM without OPENGL
Moderator: Graf Zahl
-
- Posts: 35
- Joined: Mon Mar 12, 2012 19:31
Re: Building GZDOOM without OPENGL
@Eruanna: can you please tell me whar gcc -v says on your pi, please? Mine is 6.1.0 currently, I upgraded from Raspbian's GCC months ago.
- Rachael
- Developer
- Posts: 3646
- Joined: Sat May 13, 2006 10:30
Re: Building GZDOOM without OPENGL
GCC 5.4.0 20160609 Ubuntu/Linaro
Spoiler: Complete output
-
- Posts: 35
- Joined: Mon Mar 12, 2012 19:31
Re: Building GZDOOM without OPENGL
@Eruanna: It seems I am on a newer version:
Any idea on what could be at play here?
Code: Select all
pi@raspberrypi:~ $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-6.1.0/libexec/gcc/arm-linux-gnueabihf/6.1.0/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../gcc-6.1.0/configure -v --enable-languages=c,c++ --prefix=/usr/local/gcc-6.1.0 --program-suffix=-6.1.0 --with-arch=armv6 --with-fpu=vfp --with-float=hard --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 6.1.0 (GCC)
- Rachael
- Developer
- Posts: 3646
- Joined: Sat May 13, 2006 10:30
Re: Building GZDOOM without OPENGL
Could be a regression. Could also be patches that were made in Ubuntu that are either not submitted/not approved by the official GCC maintainers. I really don't know. All I can tell you - is it works fine for me.
Raspbian and Ubuntu Mate are both Debian-based systems and both use the apt system for repository management. All Debian-based systems have at least a somewhat common folder structure and layout. You can always try to find and install Ubuntu's GCC and see if it works.
Raspbian and Ubuntu Mate are both Debian-based systems and both use the apt system for repository management. All Debian-based systems have at least a somewhat common folder structure and layout. You can always try to find and install Ubuntu's GCC and see if it works.
-
- Posts: 35
- Joined: Mon Mar 12, 2012 19:31
Re: Building GZDOOM without OPENGL
@Eruanna: Can you please configure with -DCMAKE_BUILD_TYPE=Release and tell me what optimization level is being used there by doing so?
Using "make VERBOSE=1" will tell you what's being used.
Supplying a compilation line would be great.
I think I am starting to realize what's going on here...
@Edward-san: This PR can be merged, it does what it's supposed to do. GZDoom builds without OpenGL now
Remaining problems on my system are unrelated.
Using "make VERBOSE=1" will tell you what's being used.
Supplying a compilation line would be great.
I think I am starting to realize what's going on here...
@Edward-san: This PR can be merged, it does what it's supposed to do. GZDoom builds without OpenGL now
Remaining problems on my system are unrelated.
- Rachael
- Developer
- Posts: 3646
- Joined: Sat May 13, 2006 10:30
Re: Building GZDOOM without OPENGL
Sorry I nearly forgot about this. It's running as -O3.vanfanel wrote:@Eruanna: Can you please configure with -DCMAKE_BUILD_TYPE=Release and tell me what optimization level is being used there by doing so?
Using "make VERBOSE=1" will tell you what's being used.
Supplying a compilation line would be great.
I think I am starting to realize what's going on here...
-
- Posts: 35
- Joined: Mon Mar 12, 2012 19:31
Re: Building GZDOOM without OPENGL
@Eruanna: Don't worry. Well, it's my compiler then. Building with -O2 makes the job without noticeable CPU usage increase, so it's OK now.
Also, any hopes for GLES thru SDL2 on the Pi? That would be awesome. And since (I believe) you are already using modern GL (shaders, etc) it shouldn't be hard. What do you think?
Also, any hopes for GLES thru SDL2 on the Pi? That would be awesome. And since (I believe) you are already using modern GL (shaders, etc) it shouldn't be hard. What do you think?
- Rachael
- Developer
- Posts: 3646
- Joined: Sat May 13, 2006 10:30
Re: Building GZDOOM without OPENGL
Yes - there are hopes - I had wanted to do something like that, myself, but haven't gotten very far with it yet. For the most part I was going to drop-in Beloko's D-Touch renderer, or at the very least see how it differed from GZDoom 1.8.x code and see if I could implement similar changes.
dpJudas got the software rendering framebuffer working, however as of now it crashes on ARM for an unknown reason (and does not produce a stack trace).
dpJudas got the software rendering framebuffer working, however as of now it crashes on ARM for an unknown reason (and does not produce a stack trace).
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Building GZDOOM without OPENGL
The code I added to the general OpenGL initialization in QZDoom should make the GL renderer use OpenGL ES already. If it doesn't boot, it will most likely be because of a wrong #version field in a shader, or a missing precision declaration in a fragment shader. The biggest change I had to do to the swframebuffer was to byteswap BGRA to RGBA as the BGRA order is unsupported in OpenGL ES. You may also have to fiddle with framebuffer formats if you want the postprocessing part to run, although I'm not sure any of that will be usable unless you bump the requirement to ES 3.0.
- Nash
- Developer
- Posts: 1226
- Joined: Sun Sep 25, 2005 1:49
- Location: Kuala Lumpur, Malaysia
- Contact:
Re: Building GZDOOM without OPENGL
This is most probably because of the UI scale settings inside Options -> HUD Options -> "User Interface Scale". And also Options -> HUD Options -> Message Options. Have you checked those?vanfanel wrote: -If video mode is set to 320x200 (so SDL2 makes the fullscreen scaling in hardware and CPU usage comes down dramatically) text messages appear in a GIGANTIC size
-
- Posts: 35
- Joined: Mon Mar 12, 2012 19:31
Re: Building GZDOOM without OPENGL
@Nash: Ah! that helped, thanks!
@dpJudas: Are you saying QZDoom should work with GLES2 already under SDL2???
@dpJudas: Are you saying QZDoom should work with GLES2 already under SDL2???
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Building GZDOOM without OPENGL
@vanfanel: There is some experimental OpenGL ES 2 support for the software renderer in the master branch of QZDoom. It is currently enabled automatically on ARM devices, but can be enabled on any Linux system by setting gl_es to true.
It is experimental for two reasons:
1) It worked fine when I tested it on my Linux Mint, but it only works if swtruecolor is set to false on Eruanna's RPI setup. It gives some alignment error that makes no sense (all truecolor drawers always do things 4 byte aligned), which makes me wonder if the OpenGL ES driver she got is even working. But with a broken debugger on her device I lack the smoking gun needed to know what is truly going on.
2) It also changes the GL renderer to use OpenGL ES, but I haven't even tried booting it in this mode. If you believe in miracles, this might work already. Any changes required to make this mode work will have to be PR'ed against GZDoom, along with the shared ES boot code, because it is current QZDoom policy not to fork too far from upstream. In short: if you have the right development skills, you could probably get GZDoom to run in ES mode in less than 24 hours.
It is experimental for two reasons:
1) It worked fine when I tested it on my Linux Mint, but it only works if swtruecolor is set to false on Eruanna's RPI setup. It gives some alignment error that makes no sense (all truecolor drawers always do things 4 byte aligned), which makes me wonder if the OpenGL ES driver she got is even working. But with a broken debugger on her device I lack the smoking gun needed to know what is truly going on.
2) It also changes the GL renderer to use OpenGL ES, but I haven't even tried booting it in this mode. If you believe in miracles, this might work already. Any changes required to make this mode work will have to be PR'ed against GZDoom, along with the shared ES boot code, because it is current QZDoom policy not to fork too far from upstream. In short: if you have the right development skills, you could probably get GZDoom to run in ES mode in less than 24 hours.
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: Building GZDOOM without OPENGL
Plain GZDoom won't work with GLES. Aside from shader adjustments one big issue is NPOT textures. GLES has strict requirements about those which GZDoom does not obey.
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Building GZDOOM without OPENGL
Okay, that's certainly a showstopper. Seems I was lucky the SW FB always uses clamp to edge.
-
- Posts: 35
- Joined: Mon Mar 12, 2012 19:31
Re: Building GZDOOM without OPENGL
@dpJudas: GLES support for the software renderer is (if I understand it correctly) alreday working with ZDOOM, GZDOOM, and every sourceport that works on top of SDL2, since SDL2 uses GLES2 to present the (software-rendered) frames to screen.
What I meant was hardware rendering using GLES/GLES2 instead of desktop GL.
Also, trying to build QZDoom here gives me this:
Is LLVM needed by default?
What I meant was hardware rendering using GLES/GLES2 instead of desktop GL.
Also, trying to build QZDoom here gives me this:
Code: Select all
CMake Error at tools/drawergen/CMakeLists.txt:34 (find_package):
Could not find a package configuration file provided by "LLVM" with any of
the following names:
LLVMConfig.cmake
llvm-config.cmake
Add the installation prefix of "LLVM" to CMAKE_PREFIX_PATH or set
"LLVM_DIR" to a directory containing one of the above files. If "LLVM"
provides a separate development package or SDK, be sure it has been
installed.
-- Configuring incomplete, errors occurred!