LZDoom 3.88b 02/26 released
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Got a cool project idea but nothing else? Put it in the project ideas thread instead!
Projects for any Doom-based engine are perfectly acceptable here too.
Please read the full rules for more details.
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.
Got a cool project idea but nothing else? Put it in the project ideas thread instead!
Projects for any Doom-based engine are perfectly acceptable here too.
Please read the full rules for more details.
-
- Vintage GZDoom Developer
- Posts: 3147
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
Re: LZDoom [beta 4 11/29 released]
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.
Latest beta? The next release will have asmjit as well.
-
- Posts: 816
- Joined: Sun Mar 11, 2018 4:15 pm
- Location: Venezuela
Re: LZDoom [beta 4 11/29 released]
Here's how the speed order (in my own experience) goes:drfrag wrote: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.
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49179
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: LZDoom [beta 4 11/29 released]
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 wrote:Here's how the speed order (in my own experience) goes:drfrag wrote: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.
QZDoom >> LZDoom >> GZDoom 3.x >>> GZDoom 4.x
-
- Posts: 816
- Joined: Sun Mar 11, 2018 4:15 pm
- Location: Venezuela
Re: LZDoom [beta 4 11/29 released]
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.
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.
-
- Lead GZDoom+Raze Developer
- Posts: 49179
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: LZDoom [beta 4 11/29 released]
TDRR wrote: 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.
-
- Posts: 816
- Joined: Sun Mar 11, 2018 4:15 pm
- Location: Venezuela
Re: LZDoom [beta 4 11/29 released]
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 wrote:It may be because LZDoom still contains the single threaded software renderer
-
- Lead GZDoom+Raze Developer
- Posts: 49179
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: LZDoom [beta 4 11/29 released]
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.
-
- Vintage GZDoom Developer
- Posts: 3147
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
Re: LZDoom [beta 4 11/29 released]
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.
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.
-
- Vintage GZDoom Developer
- Posts: 3147
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
Re: LZDoom [beta 4 11/29 released]
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.
Edit: Now on intel GMA 4500M win 7: LZDoom 85 fps vs GZD 3.4.1 30 @1280 both x64.
Last edited by drfrag on Mon May 06, 2019 8:27 am, edited 2 times in total.
-
-
- Posts: 3132
- Joined: Sat May 28, 2016 1:01 pm
Re: LZDoom [beta 4 11/29 released]
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.
-
-
- Posts: 3132
- Joined: Sat May 28, 2016 1:01 pm
Re: LZDoom [beta 4 11/29 released]
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.
-
- Vintage GZDoom Developer
- Posts: 3147
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
Re: LZDoom [beta 4 11/29 released]
It was 3.3.2 but LZDoom has a lot of later stuff. https://github.com/drfrag666/gzdoom/tree/g3.3mgw
-
-
- Posts: 3132
- Joined: Sat May 28, 2016 1:01 pm
Re: LZDoom [beta 4 11/29 released]
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.
-
- Vintage GZDoom Developer
- Posts: 3147
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
Re: LZDoom [beta 4 11/29 released]
I've hooked the continuous integration services and LZDoom doesn't compile on MacOS since "- fixed mouse cursor positioning in menu for Cocoa backend".
This codebase is from before the merging of the renderers.
@_mental_: What should i do? Just revert it?
Code: Select all
/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;
@_mental_: What should i do? Just revert it?
-
- Posts: 816
- Joined: Sun Mar 11, 2018 4:15 pm
- Location: Venezuela
Re: LZDoom [beta 4 11/29 released]
Forgot to say, after using r_multithreaded 2 (i think that was the command?) The framerate issue in software mode got fixed.