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 » Fri Jan 20, 2017 19:23

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

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

Re: Building GZDOOM without OPENGL

Post by Rachael » Fri Jan 20, 2017 19:40

GCC 5.4.0 20160609 Ubuntu/Linaro
Spoiler: Complete output
Spoiler: Zen Sarcasm

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

Re: Building GZDOOM without OPENGL

Post by vanfanel » Fri Jan 20, 2017 23:33

@Eruanna: It seems I am on a newer version:

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)
Any idea on what could be at play here?

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

Re: Building GZDOOM without OPENGL

Post by Rachael » Sat Jan 21, 2017 0:23

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

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

Re: Building GZDOOM without OPENGL

Post by vanfanel » Sat Jan 21, 2017 14:21

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

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

Re: Building GZDOOM without OPENGL

Post by Rachael » Mon Jan 23, 2017 19:35

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...
Sorry I nearly forgot about this. It's running as -O3.
Spoiler: Zen Sarcasm

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

Re: Building GZDOOM without OPENGL

Post by vanfanel » Thu Jan 26, 2017 14:00

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

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

Re: Building GZDOOM without OPENGL

Post by Rachael » Thu Jan 26, 2017 16:45

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

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

Re: Building GZDOOM without OPENGL

Post by dpJudas » Fri Jan 27, 2017 1:34

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.

User avatar
Nash
Developer
Developer
Posts: 1226
Joined: Sun Sep 25, 2005 1:49
Location: Kuala Lumpur, Malaysia
Contact:

Re: Building GZDOOM without OPENGL

Post by Nash » Fri Jan 27, 2017 10:27

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
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
Posts: 35
Joined: Mon Mar 12, 2012 19:31

Re: Building GZDOOM without OPENGL

Post by vanfanel » Sat Jan 28, 2017 22:40

@Nash: Ah! that helped, thanks!

@dpJudas: Are you saying QZDoom should work with GLES2 already under SDL2???

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

Re: Building GZDOOM without OPENGL

Post by dpJudas » Sun Jan 29, 2017 2:50

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

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Building GZDOOM without OPENGL

Post by Graf Zahl » Sun Jan 29, 2017 10:14

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.

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

Re: Building GZDOOM without OPENGL

Post by dpJudas » Sun Jan 29, 2017 10:32

Okay, that's certainly a showstopper. Seems I was lucky the SW FB always uses clamp to edge.

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

Re: Building GZDOOM without OPENGL

Post by vanfanel » Sun Jan 29, 2017 14:02

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

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!

Is LLVM needed by default?

Locked

Return to “Technical Support”