LZDoom 3.84 12/16 released

[drfrag]

But slower than which version? Do you mean it's faster than GZDoom but slower than QZDoom? What hardware?
Latest beta? The next release will have asmjit as well.

[TDRR]

But slower than which version? Do you mean it's faster than GZDoom but slower than QZDoom? What hardware?
Latest beta? The next release will have asmjit as well.

Here's how the speed order (in my own experience) goes:

QZDoom >> LZDoom >> GZDoom 3.x >>> GZDoom 4.x

The hardware is your typical boring low-end craptop:
Celeron 1.4GHz
Intel HD 4000
2GB RAM

I did expect the speed increase in this PC, because, well, it has "modern" qualities to it, but my desk PC also is very noticeably faster:
Intel Pentium Dual-Core 3GHz (Really good for Software-render Dooming btw)
Intel G41 Express Chipset
2GB RAM

If by latest beta you mean beta 4, then yes that is the case.

[Graf Zahl]

But slower than which version? Do you mean it's faster than GZDoom but slower than QZDoom? What hardware?
Latest beta? The next release will have asmjit as well.

Here's how the speed order (in my own experience) goes:

QZDoom >> LZDoom >> GZDoom 3.x >>> GZDoom 4.x

That cannot be. QZDoom is basically the same code as early GZDoom 3.x, and even built with the same compiler. Something on your system must be doing very weird things here. Have you tried renaming the EXEs to see what happens then?

[TDRR]

Nothing, really, but perhaps it is that i have never tested GZDoom 3.4 with the software renderer on my laptop? I did do so on my desk PC but at that point i never really paid attention to framerate, all i knew is that it was above 70fps, so when i tried QZDoom on my laptop it was when i noticed the pretty big speed advantage. Maps like Skulltag's CTF maps suddenly became smoothly playable (talking more than 50fps on a garbage laptop)

Still, the point is it's faster than LZDoom, when i was expecting the opposite, i'm curious as to why this is.

EDIT: There's indeed a speed difference in GZD 3.4 vs QZD 2.1, in QZD i get 220fps in Doom 2 MAP01, while in GZD i get 210fps in the same conditions. Minimal impact, but it's there. All of this is in 100% exact same default settings.

[Graf Zahl]

Still, the point is it's faster than LZDoom, when i was expecting the opposite, i'm curious as to why this is.

It may be because LZDoom still contains the single threaded software renderer, or it's because of the compiler being used.
One other thing about the software renderer is that in 64 bit it is significantly faster than in 32 bit.

[TDRR]

It may be because LZDoom still contains the single threaded software renderer

I'm 99% certain that is indeed the case, this laptop's single core performance is garbage, and the dual core performance is, well, garbage too, but less so. Both of my PCs are running Windows 7 64bit so that's unlikely to be the cause of the massive difference.

[Graf Zahl]

Did you run a 64 bit build of LZDoom? I only can tell you that on my system the difference between 32 bit and 64 bit code is quite significant when running the software renderer, so using a different compiler with a weaker optimizer can really make a big difference here.

[drfrag]

LZDoom has the multithreaded software renderer and even then you could select the number of threads and besides D3D was faster than OpenGL. But all those things about the numa nodes are not in LZDoom, they made the engine crash at high resolutions. Did they made that much of a diffference?
Also if you use MinGW-w64 you'll get poor performance in software due to the library they're using. BTW now the 64 bit MinGW build crashes but that's a completely different thing about event handlers, unless i make the switch to unicode. I'll run some tests here.

[drfrag]

I've made the comparison and LZDoom is much faster and it's not equivalent to 3.3.2 at all. For some reason on this laptop (Radeon R2) i can't disable vsync for D3D so it's stuck at 60 fps (@1366 truecolor), with GZD 3.4.1 i get 10. There was a severe performance problem for amd and intel on those old versions in software and i ported the fix for OpenGL software but that backend was still somewhat experimental. Same happens here with 3.3.2 but i remember performance being very good when i made comparisons on other machines, here i'm on windows 10. Anyway sticking to such an old version doesn't make sense when there's a vintage build, latest is a bit hacky tough.
Edit: Now on intel GMA 4500M win 7: LZDoom 85 fps vs GZD 3.4.1 30 @1280 both x64.

[dpJudas]

The NUMA stuff never made any speed difference on my system. The purpose of it was to split the frame buffer into four parts - one for each compute complex in the AMD Threadripper CPU. A dual core CPU does not have a NUMA architecture and it should have no effect there.

[dpJudas]

By the way, which was the last version of GZDoom that still had the D3D9 backend? Since that version performed a lot better than what we have now I've been thinking about using it for transfering the frame buffer data and then try use that surface directly from Vulkan.

[drfrag]

It was 3.3.2 but LZDoom has a lot of later stuff. https://github.com/drfrag666/gzdoom/tree/g3.3mgw

[dpJudas]

It was mostly to look at the D3D9 init and copy code. I want to try see what happens if I create a D3D9 surface, upload to it using the same method as old ZDoom did, then, using Vulkan's DXGI interop feature, import that surface into Vulkan and render it.

[drfrag]

I've hooked the continuous integration services and LZDoom doesn't compile on MacOS since "- fixed mouse cursor positioning in menu for Cocoa backend".

Code: Select all • Expand view

/Users/travis/build/drfrag666/gzdoom/src/posix/cocoa/i_input.mm:487:30: error: no member named 'GetTrueHeight' in 'DFrameBuffer'
        outEvent->data2 += (screen->GetTrueHeight() - screen->VideoHeight) / 2;

This codebase is from before the merging of the renderers.
@_mental_: What should i do? Just revert it?

[TDRR]

Forgot to say, after using r_multithreaded 2 (i think that was the command?) The framerate issue in software mode got fixed.