[defunct] Experimental release based on GZDoom 4.6.0+GLES

[Graf Zahl]

On what hardware? Also keep in mind that GLESZDoom removes some features that would slow down older hardware too much.

[drfrag]

I'd love to see how such hardware (Geforce 6800, Geforce 7800/7900) or (Radeon 9800 Pro/X850 XT/X1900) will run GZDoom GLES at 1080p utilizing this.

We don't know if it will run on GL2 AMD hardware without changing the context creation code, on intel for sure it won't. And does the software renderer run on it now?
Edit: nope i still get the "Unable to map buffer for software rendering" error.

[emile_b]

I noticed that in this version of the port, in OpenGL mode the FPS is higher than in the regular GZDoom4.6.0.
https://imgur.com/a/07JOzn1

Oh yeah the existing OpenGL renderer in that build also has the 'pipelined buffer' change, seems to help for for some cards.

[vaa44]

On what hardware? Also keep in mind that GLESZDoom removes some features that would slow down older hardware too much.

Athlon x2 2.7GHz
GTS450
4GB DDR2-800MHz
Win7x64

So OpenGL renderer in GZDoom and GLESZDoom are different ?

[Redneckerz]

Updated to 4.6.0a - this has the new launcher window with the OpenGLES option.

Thanks for this Rach - Makes it even more easier to set up.

I'd love to see how such hardware (Geforce 6800, Geforce 7800/7900) or (Radeon 9800 Pro/X850 XT/X1900) will run GZDoom GLES at 1080p utilizing this.

We don't know if it will run on GL2 AMD hardware without changing the context creation code, on intel for sure it won't. And does the software renderer run on it now?
Edit: nope i still get the "Unable to map buffer for software rendering" error.

That's why we need more testing. My performance is about as good as it gets for ultra down the barrel hardware - But how does it perform at today's gaming's common resolutions (1080p and up)?

Based on the scaling, i'd imagine that high end OGL2 cards will hit 60 FPS at that resolution, especially when pared with something timeframe specific, like early Core 2 Duo, Core Duo, or even Pentium D (Albeit that will be a stretch).

On what hardware? Also keep in mind that GLESZDoom removes some features that would slow down older hardware too much.

Athlon x2 2.7GHz
GTS450
4GB DDR2-800MHz
Win7x64

That GPU would be modern enough to run regular GZDoom (OpenGL 4.6) but the rest of the specs is about what i would expect GZDoom-GLES to be useful at.

So OpenGL renderer in GZDoom and GLESZDoom are different ?

Beloko's renderer is OpenGLES 2.0 based and is tailored for mobile hardware (Mali 400 and consorts, which are still hugely popular mobile GPU's, have GLES2 as a baseline) with the benefit of running also on PC for GPU's with OpenGL 2.1 support.

GZDoom's renderer requires OpenGL 3.3 for hardware rendering and D3D9 for software. It also supports a lot more eyecandy.

[emile_b]

So OpenGL renderer in GZDoom and GLESZDoom are different ?

Yes there is a small difference in the way it runs which may effect performance either way, but it should look and run the same otherwise

[adamhossam]

how do i use the master branch?

[Rachael]

There are no dev builds available for this - so you would have to compile it yourself, or simply wait for a new release with the changes. Right now there are no significant changes from the master branch to be concerned with, so at the moment at least, you aren't missing anything.

[adamhossam]

ok thanks!

[Delfino Furioso]

I've been testing this with Goulden Souls 3 beta 2, which has always been the most taxing wad on my system (a laptop with intel's i7-8565U and UHD Graphics 620).
Performance are very promising!

gzdoom 4.6.0 opengl backend
title map: average framerate around 130 fps
starting tutorial rooms: average framerate around 250 fps
town hub map: average framerate around 35 fps

gzdoom-gles 4.6.0a opengl backend
title map: average framerate around 200 fps
starting tutorial rooms: average framerate around 350 fps
town hub map: average framerate around 60 fps

gzdoom-gles 4.6.0a gles2 backend
title map: average framerate around 300 fps
starting tutorial rooms: average framerate around 690 fps 720 fps when using 4.6.0b
town hub map: i get a "very fatal error" when gzdoom tries to load the map fixed in 4.6.0b, now getting an average of 85 fps

The crash happens either when going through the portal at the end of the tutorial rooms or when using the "map" console command
I'll post the generated Crash Reports in the bugs forum.


Thank you and keep up the good work!

[Graf Zahl]

Out of curiosity, how does Gzdoom with Vulkan fare on that system?

[Delfino Furioso]

Out of curiosity, how does Gzdoom with Vulkan fare on that system?

gzdoom 4.6.0 vulkan backend
title map: average framerate around 105 fps
starting tutorial rooms: average framerate around 175 fps
town hub map: average framerate around 40 fps

gzdoom-gles 4.6.0a vulkan backend
basically the same as standard gzdoom 4.6.0

as a side note: using vulkan I get wider difference between min/max peak framerate, in contrast to using opengl3 which results in peak framerates closer to the average value

[Rachael]

Updated to 4.6.0b with some new fixes.

[Delfino Furioso]

Updated to 4.6.0b with some new fixes.

thank you!
using this new release I was able to complete my tests

gzdoom-gles 4.6.0a gles2 backend
title map: average framerate around 300 fps
starting tutorial rooms: average framerate around 720 fps
town hub map: getting an average of 85 fps

note that the town hub is now rendered differently, with the final result similar to when one set fullbright on
I guess that it is due to the change in gl_customshader default value (now false) - right?
also, if I set that cvar value to true then the game crashes again when loading the hub map (a confirmation that the issue lied in the shaders management code, i guess)

[emile_b]

Thanks Rachael.

note that the town hub is now rendered differently, with the final result similar to when one set fullbright on
I guess that it is due to the change in gl_customshader default value (now false) - right?
also, if I set that cvar value to true then the game crashes again when loading the hub map (a confirmation that the issue lied in the shaders management code, i guess)

Yeah I removed the code which loads custom shaders from the GLES renderer. This was only done so I knew exactly what shader code was running, however there is no reason why custom shaders can not at least attempt to be loaded for GLES and give the user to the option to turn them on/off. I'll look at putting that code back in