LZDoom 3.84 released

[Rachael]

It's already available now - in the current master.

You will have to launch with "./gzdoom +vid_preferbackend 2 +vid_rendermode 0" - and then you should be able to use the software renderer with any backend SDL supports.

[drfrag]

He wanted to run the GL renderer with GLES2 so i guess he'll be more interested in Softpoly II.

I've tried to add support for 4 XInput controllers (not that it's actually needed) but it's a blind shot, here's a test build:
https://devbuilds.drdteam.org/lzdoom/lz ... ed15efc.7z
And for nostalgic people another pirated vintage devbuild:
https://devbuilds.drdteam.org/gzdoom-vi ... 91fe036.7z

[Redneckerz]

He wanted to run the GL renderer with GLES2 so i guess he'll be more interested in Softpoly II.

I've tried to add support for 4 XInput controllers (not that it's actually needed) but it's a blind shot, here's a test build:
https://devbuilds.drdteam.org/lzdoom/lz ... ed15efc.7z
And for nostalgic people another pirated vintage devbuild:
https://devbuilds.drdteam.org/gzdoom-vi ... 91fe036.7z

Oh i know where you got that latter build from. Thanks frag!

[vanfanel]

@Rachael: Great!
Is this the repository to get the master sources for lzdoom? --> https://github.com/drfrag666/gzdoom/tree/legacy

What build options should I use for SDL2 with no desktop GL? (SDL2 runs on GLES and GLES2 renderers).

[Rachael]

I wasn't referring to LZDoom. If you want to use that, it still supports the same backends that GZDoom 3.3 did.

GZDoom 4.3 now has a SoftPoly II backend that should also support the GLES 2.0 backend (or anything else that SDL2 supports).

LZDoom is here -> https://github.com/drfrag666/gzdoom/tree/g3.3mgw (g3.3mgw branch)
GZDoom is here -> https://github.com/coelckers/gzdoom/tree/master (master branch)

If I am not mistaken your use case is the Raspberry Pi without X? Both will run on it. LZDoom is likely to run better on it, but try both and see.

LZDoom you can run like this -> ./lzdoom +vid_renderer 0
GZDoom you can run like this -> ./gzdoom +vid_rendermode 0 +vid_preferbackend 2

[drfrag]

I thought SoftPoly II was 'vid_rendermode 4' and not the backend itself. I was referring to the new renderer or rasterizer.

[Rachael]

No. vid_rendermode 4 works differently depending on the backend, and with the softpoly backend it activates the new actual softpoly mode. If you're using OpenGL or Vulkan it uses the regular hardware poly mode (fka OpenGL renderer) that we've all grown to love over the years.

vid_rendermode 2 and 3 no longer work, the support code for those was removed. They'll just activate the classic software renderer for now.

But that being said, softpoly can only be specified at startup or prior to a restart.

[drfrag]

That's what i meant, vid_rendermode 4 with the poly backend.

[vanfanel]

I wasn't referring to LZDoom. If you want to use that, it still supports the same backends that GZDoom 3.3 did.

GZDoom 4.3 now has a SoftPoly II backend that should also support the GLES 2.0 backend (or anything else that SDL2 supports).

LZDoom is here -> https://github.com/drfrag666/gzdoom/tree/g3.3mgw (g3.3mgw branch)
GZDoom is here -> https://github.com/coelckers/gzdoom/tree/master (master branch)

If I am not mistaken your use case is the Raspberry Pi without X? Both will run on it. LZDoom is likely to run better on it, but try both and see.

LZDoom you can run like this -> ./lzdoom +vid_renderer 0
GZDoom you can run like this -> ./gzdoom +vid_rendermode 0 +vid_preferbackend 2

Yes: I am trying to run it on X-less SDL2 on GLES2.
So I went and cloned LZDoom like this:

Code: Select all

git clone --depth 1 -b g3.3mgw https://github.com/drfrag666/gzdoom.git

And built like this:

Code: Select all

cmake -DCMAKE_C_FLAGS="-march=armv8-a+crc -mtune=cortex-a53" -DCMAKE_CXX_FLAGS="-march=armv8-a+crc -mtune=cortex-a53"  -DCMAKE_BUILD_TYPE=Release ..
make -j3

But resulting executable does not run:

Code: Select all

./lzdoom +vid_renderer 0

Results in:

Code: Select all

OpenGL load failed. No OpenGL acceleration will be used.

I still have to try GZDoom instead of LZDoom.

[Rachael]

Hmm. If LZDoom didn't work, I don't know if GZDoom will, then. LZDoom is exactly the state of the code back in the day when it did work for GZDoom... But yeah, try it out and see what happens... if it doesn't work though, sorry, not much I can do, because this is not a setup I have ever used... I run everything on X, even if it's just a bare X server with no WM/DE.

[vanfanel]

Hmm. If LZDoom didn't work, I don't know if GZDoom will, then. LZDoom is exactly the state of the code back in the day when it did work for GZDoom... But yeah, try it out and see what happens... if it doesn't work though, sorry, not much I can do, because this is not a setup I have ever used... I run everything on X, even if it's just a bare X server with no WM/DE.

Well, as you guessed GZDoom does not work either: "Failed to load OpenGL functions".

X-less enviroments also work in X86 using the SDL2 KMSDRM driver, its not something exclusive from small ARM SBCs. So maybe you can test in such an enviroment, no need to kill the Xorg server, just switch to any TTY (and have a KMSDRM-enabled SDL2 build installed, of course), just in case you feel like testing.

It is just a matter of building SDL2 with:

Code: Select all

./configure --enable-video-kmsdrm

I am almost sure it is something with GLES vs OpenGL. And it worked years ago with ZDoom.

[Phredreeke]

Would LZDoom be recommended over GZDoom for a low end OpenGL 4.5 compatible GPU? (more specifically, a Cherry Trail Atom SoC)

Apologies if I'm asking this in the wrong place, I couldn't find any dedicated LZDoom thread

[Graf Zahl]

No. Absolutely not. For such hardware it uses mostly the same render path. The major change between LZDoom and GZDoom in the modern render path only impacts performance on GL 2 hardware, we had this tested on a first generation Geforce GL 3 card and the old renderer provided no advantage.