[No] Running GLES renderer via ANGLE

[Phredreeke]

This idea came about reading ReX's ongoing issues getting with getting GZDoom to run on Win10.

ANGLE is used on Google Chrome among other software to translate OpenGL calls to Direct3D equivalents and is licensed under the BSD license. Would it be possible to use it in a way similar to how MoltenVK is used on Macs to run the GLES renderer on systems without OpenGL support?

[drfrag]

It was commented on Discord. Cacodemon345 tried and it was extremely slow on old hardware. But i don't know which hardware, being a wrapper it will require a fast cpu.

[Rachael]

It's not a bad idea, but, as drfrag said it's a wrapper. I think the only way this will work is if it is implemented as an extra add-on download.

[Graf Zahl]

It won't do much good. Pre-GL3 hardware's shaders are simply far too weak.

[Rachael]

Well - it can't hurt to try. Knowing it's going to be painfully slow and seeing it be painfully slow are two different things.

Nevertheless I scrapped these two .dll files up from my Google Chrome installation. I had troubles compiling Angle myself - the instructions are confusing and whatever I was able to follow simply didn't work. It didn't really seem worth my time trying much more of it. But since Chrome uses Angle anyhow, I figured I could harvest the .dll's straight from it.

I am not sure if this even works with GZDoom - I didn't notice a difference having them there.

https://drive.google.com/file/d/1bZRMB2 ... sp=sharing

[Graf Zahl]

I really wish that some of all this potato-related work was invested in something useful for owners of modern hardware...

[drfrag]

But have you compiled the application with ANGLE support?

[Redneckerz]

But have you compiled the application with ANGLE support?

Go even weirder and try compiling GZDoom with TinyGLES support.

This would actually make up for a similar concept seen in the Engoo source port - Purely software rendered with tons of eye candy, designed for pure CPU grunt.

[Phredreeke]

At that point you might as well use Softpoly

[Graf Zahl]

My vision of GZDoom's feature means eventual removal of all backends aside from Vulkan.

Remember: This currently would mean serving 85% of the existing users, and those last 15% will only decline as time goes on - especially now with Windows 11 on the horizon, I'd expect it to accelerate.
Our current hardware support means that the most recent hardware that is not supported fully is the Intel HD3000 from 2011. And the most recent discrete graphics cards no longer supported are from 2005/2006! Do we really need those last few users on hardware so old that it's a miracle it still works? Once we got support in, the code needs to be maintained. I won't do it.

Even with the GLES backend I only see it as something temporary that will eventually fall off the support roster once mobile GPUs stop being shit. THe entire thing is very unconductive toward new feature implementations and will very likely be treated as thre ugly step child nobody likes but has to treat nicely. Much the same for Softpoly. It's also some heavy Millstone around the neck that complicates matters for very little gain. It is fine for presenting the software renderer's output, but again we got a full additional backend just for a single percent of users.

If this trend of adding even more dead end support continues I may just consider forking the project, clean out the cruft and do a forward looking port unencumbered by the needs of dying hardware.

[Phredreeke]

Yeah, this would be better relegated to LZDoom if it was actually beneficial to performance, which from the sound of it it's not.

[dpJudas]

For what it's worth, my stance on this is in alignment with what Graf said. There are certain things that gets a lot more complicated to do once you have to support multiple backends. In some test branches of mine I already first dropped all the other backends just to avoid having to do everything three times (four times now with the GLES backend).

Anything related to the hardware renderer interface is pretty much locked in stone. When the time comes to needing to upgrade that I suggest dropping everything than vulkan and then if it matters enough some developers can port over the other backends (possibly as sister projects to GZDoom itself). If no developers jump in to do that then IMO there wasn't enough interest. As for softpoly, I had my fun with that thing so if it causes any problems for future hardware renderer changes I'm all for dropping it.

[Graf Zahl]

I'd keep softpoly as a fallback for the software renderer but probably disable 3D on it. It is too slow anyway for serious use.
In Raze I already dropped it because it did not work right there and serves no purpose without a software renderer.

As I see it, the Vulkan renderer is heavily restrained by having to work on a setup that also needs to support OpenGL, this prohibits a lot of things that'd allow to speed it up.

[Graf Zahl]

Yeah, this would be better relegated to LZDoom if it was actually beneficial to performance, which from the sound of it it's not.

LZDoom has reached the end of the line in its current incarnation. Should this really happen I'd rename the nee port, not the existing one.

[Nash]

Pretty much in agreement with Graf and dpJudas. Softpoly is still useful for the Carmack renderer. But otherwise, GZDoom should keep going forward. There are plenty of other source ports that cater to low end equipment.

(While working to resurrect the lightmaps branch, it just dawned on me how much of an inconvenience it is to do the same work 3 - 4 times...)