Page 2 of 6

Re: Building GZDOOM without OPENGL

Posted: Fri Jan 20, 2017 19:23
by vanfanel
@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.

Re: Building GZDOOM without OPENGL

Posted: Fri Jan 20, 2017 19:40
by Rachael
GCC 5.4.0 20160609 Ubuntu/Linaro
Spoiler: Complete output

Re: Building GZDOOM without OPENGL

Posted: Fri Jan 20, 2017 23:33
by vanfanel
@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?

Re: Building GZDOOM without OPENGL

Posted: Sat Jan 21, 2017 0:23
by Rachael
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.

Re: Building GZDOOM without OPENGL

Posted: Sat Jan 21, 2017 14:21
by vanfanel
@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.

Re: Building GZDOOM without OPENGL

Posted: Mon Jan 23, 2017 19:35
by Rachael
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.

Re: Building GZDOOM without OPENGL

Posted: Thu Jan 26, 2017 14:00
by vanfanel
@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?

Re: Building GZDOOM without OPENGL

Posted: Thu Jan 26, 2017 16:45
by Rachael
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).

Re: Building GZDOOM without OPENGL

Posted: Fri Jan 27, 2017 1:34
by dpJudas
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.

Re: Building GZDOOM without OPENGL

Posted: Fri Jan 27, 2017 10:27
by Nash
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?

Re: Building GZDOOM without OPENGL

Posted: Sat Jan 28, 2017 22:40
by vanfanel
@Nash: Ah! that helped, thanks!

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

Re: Building GZDOOM without OPENGL

Posted: Sun Jan 29, 2017 2:50
by dpJudas
@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.

Re: Building GZDOOM without OPENGL

Posted: Sun Jan 29, 2017 10:14
by Graf Zahl
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.

Re: Building GZDOOM without OPENGL

Posted: Sun Jan 29, 2017 10:32
by dpJudas
Okay, that's certainly a showstopper. Seems I was lucky the SW FB always uses clamp to edge.

Re: Building GZDOOM without OPENGL

Posted: Sun Jan 29, 2017 14:02
by vanfanel
@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?