ZDoom

great, thank you!

>>do not precache unreferenced textures

big thanks!

mjr4077au wrote:
Irrespective of Graf, I'm certainly pleased! Well done, what a step up

Haha, thanks This was a steal considering this was to be retired, but overall the machine is still worth a few pennies. Just ordered a 1 TB HDD and a 2 TB external HDD which were delivered yesterday.

As a matter of testing ill put GZDoom and GZDoom-GLES to the test on the new rig and see how it goes.

Rachael wrote:GLES branch version 4.6.1 released. First post edited with download links.

Much appreciated, Rachael. Is EmileB still working alongside it?

If development continues, ill put something on the wiki about it. Great to have this version that does all that mainline GZ does but keeps the rendering to other places.

Yes - actually the code for that release was prepared entirely by Emile He offered to gather up the commits he wanted for it and put in Graf's cherry-picks for them too and then gave me a ready-to-compile source tree. I would've done it myself but I had a busy day and he offered to do it so I figured why not.

Many thanks - great work!

WOOHOO!

Rachael wrote:GLES branch version 4.6.1 released. First post edited with download links.

Thanks very much for the gles version Runs even smoother than LZDoom my old laptop for some reason (on which I can't even boot regular GZDoom)

Are you planning to update the gles branch according the next GZDoom releases ?

I would like to do that, yes, but eventually I am hoping we can just merge the whole thing into GZDoom proper.

For that someone needs to clean up the buffer pipelining code so that it can coexist with the fully featured renderer and make sure that this doesn't require disabling shader storage buffers which are needed for large numbers of dynamic lights and shadowmaps.


Aside from this thing the rest should be very easy to handle. All things combined it's less than 500 lines of changed code for everything and the vast majority of that is the pipelining stuff with multiple buffers.

Well, I merged the GLES changes into a work branch. Seems to work overall - the pipelining stuff brings a minor performance boost, but the tradeoff with disabling some features is too high for me, so this won't get exposed to the menu for the full GL renderer.

Aside from that there's an issue with the weapon sprite in the GLES2 renderer when using a fullscreen colormap, but aside from this it seems to work.
On my Geforce 1060 the GLES renderer is quite a bit slower than the full one, though. Seems all the shader switching is too costly on modern hardware that can handle a super-shader.

Needs a review, though.

ClessxAlghazanth wrote:Runs even smoother than LZDoom my old laptop for some reason (on which I can't even boot regular GZDoom)

On which hardware?
Last time i tried it the GLES backend still could not run the software renderer.

It can't - do we need it? At least on Windows we got D3D9 as fallback for that and on macOS such old hardware is completely irrelevant by now.

Well it would be nice to be able to at least run it on GL2 but on my intel laptop GLES crashed. But yes there's softpoly2.

Rachael wrote:I would like to do that, yes, but eventually I am hoping we can just merge the whole thing into GZDoom proper.

Great to hear that Would there be a option to choose the regular or the gles version in the video options menu ?

drfrag wrote:On which hardware?
Last time i tried it the GLES backend still could not run the software renderer.

i3 laptop with 4gb ram , Windows 8 (64-bit)

I see But for some reason for OpenGL mode Gzdoom-gles runs smoother than LZDoom for me , isn't latest GZDoom supposed to be running more advanced and complicated code ? I'm surprised just adding a new renderer gives such a performance boost

About LZDoom , while sw renderer runs fine , with opengl one I'm getting slowdown and lags after 3.85 , before that it was mostly full speed

But again on which hardware? Is 3.85 still fast now? I haven't seen any performance regression on my hardware.