DRD Team

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.

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

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.

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.

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.

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.

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?

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.

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

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.

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

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.

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

_mental_ would know more about that than I do, I think.

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.