LZDoom 3.86a released

[drfrag]

I doubt softpoly was faster than 8 bit Carmack, on windows 8 bit now gives the same performance as 32 bit in software.
I've uploaded the 3.86a tag, for linux i've realized that thing could be a problem as many use the command line and i forgot there's also an iwad picker there. Now it's not shown when using the -iwad parameter.

[drfrag]

Released 3.86a.

[Hexereticdoom]

I've uploaded the 3.86a tag, for linux i've realized that thing could be a problem as many use the command line and i forgot there's also an iwad picker there. Now it's not shown when using the -iwad parameter.

Thanks for the hotfix! It is much better this way. Now it works like before, both on Linux and on Windows...

[Kamil]

New release of LZDoom. Really cool

[mjr4077au]

I doubt softpoly was faster than 8 bit Carmack, on windows 8 bit now gives the same performance as 32 bit in software.
I've uploaded the 3.86a tag, for linux i've realized that thing could be a problem as many use the command line and i forgot there's also an iwad picker there. Now it's not shown when using the -iwad parameter.

8-bit softpoly was as fast as the 8-bit carmack renderer from my own testing. I just think having a 32-bit softpoly as the only pathway will be detrimental to your port as 32-bit software rendering performance sucks...

Prime example, my old Core i5 2500 and Radeon 5850 from 2009. In the latest GZDoom, I can get 200-300fps on stock Doom levels at 1080p, but absolutely can't manage that in SoftPoly without scaling the resolution which doesn't look great. I'm sure an even older GPU like a GeForce 9-200 series would be able to out-perform SoftPoly for the most part.

[Graf Zahl]

The main purpose of the softpoly backend is to serve as a fallback for the classic software renderer so who cares? The old softpoly sucked anyway it was way too incomplete.

[mjr4077au]

The main purpose of the softpoly backend is to serve as a fallback for the classic software renderer so who cares? The old softpoly sucked anyway it was way too incomplete.

My point is LZDoom at least in my mind was meant for low-end hardware that couldn't run GZDoom and with LZDoom moving towards SoftPoly, if I can't run it acceptably well on a Core i7 4770k then I don't think a lot of the target audience for LZDoom would be able to either.

I can't even run the Carmack renderer on SoftPoly with an acceptable performance level and older computers with OpenGL 2.x only cards wouldn't even be able to run the actual Carmack renderer directly because the canvas is OpenGL 3.3+. Hopefully the DX9 backend for the software renderer remains in LZDoom.

[drfrag]

Are you sure you're running an optimized build? Performance for me AFAIR is similar to the old GL2 render path on crappy intel cards for softpoly itself on lowend, i made a comparison and we posted results somewhere but i can't remember where it is.
8 bit softpoly was fast but much slower than the carmack renderer. I believe 8 bit softpoly was hard to implement on polybackend and dpJudas didn't do it. You can't compare nvidia hardware with software rendering. So you don't consider resolutions below 4K acceptable? I'm fine with playing software mode in lowres, this is Doom after all not Far Cry.
Anyway carmack runs well on softpoly and it's much faster than softpoly 2 itself as expected.
The main purpose of softpoly is to run the software rasterizer i believe and then dpJudas hooked the carmack renderer. The old softpoly was great but had serious problems, i guess making a fully polygonal software renderer for Doom wasn't easy but nonetheless it was a big achievement.
Softpoly runs on D3D9 and replaces the ancient D3D backend, it could be faster on 8 bits with some shaders but i don't know if dpJudas plans to implement them someday. But even now 8 bit carmack is fast enough, much faster than the rasterizer/polygonal renderer as i've said.

[mjr4077au]

When I built from your master branch, I built a Release x64 build. But nonetheless, testing between GZDoom 4.2.4 and 4.3.0 release builds from Github demonstrates the performance issues. I even commented on the perf issues on release.

I'm happy to test again and provide logs/data but I just don't get great performance of the Carmack renderer on SoftPoly vs running it direct/over OpenGL. My experience to sum it up is basically that 8-bit SoftPoly from 4.2.x runs as fast on stock maps as the Carmack renderer and that SoftPoly running the Carmack renderer nowhere near as fast as just running the Carmack either over OpenGL in GZDoom or D3D9 in LZDoom.

Perhaps I should take this to a different thread if you want to keep talking about it? I only raise it because I find the upcoming changes for LZDoom surprising just from my own perf experiences, didn't mean to take the release notes off-topic.

[drfrag]

But you haven't tested on lowend hardware, here on my radeon r2 the new softpoly @800 is 30% faster than the old 32 bit softpoly thru OpenGL (i've checked an old thread). And for 8 bit there was not that much of a difference. On my ancient intel GL2 card i got pretty much the same performance @712x400 at hot spots. And carmack is much faster anyway. This is not a fps contest, i mainly care about the minimum fps and not the maximum. And LZDoom is not meant only for legacy hardware, it's the legacy/classic version with old ZDoom code/features. Again you can't compare nvidia hardware with software.

[mjr4077au]

I thought the old Radeon 5850 from 2009 was low end enough these days but perhaps not. I also wasn't comparing the NVIDIA hardware as per my profile, only the aforementioned Radeon. The NVIDIA GPU is in my main PC. Not sure where the 4K business came from either, I was only talking about 1080p back in one of the posts.

Sorry also that I got the scope of LZDoom wrong, I should have made myself more aware of the port's goals before commenting. I guess all I was trying to say that was my half decent computer from 2010 with its half decent GPU from that same era can run rings around what SoftPoly can perform at and I'd assume a half decent computer from ~2007 wouldv that'd certainly require the OGL 2.x pathway would be the same.

[drfrag]

On intel hardware certainly performance is independent of resolution and you got much higher max frame rates (my old laptop is from 2008, intel GMA 4500M), but when it matters it tanks. In fact Mesa3D software was not that much slower, it was a partially software implemented solution with crappy drivers after all.
No problem, i mean LZDoom mainly targets older hardware but it's not only about that.
Edit: precisely the custom shaders syntax has changed in 4.4 and that's a problem. I backported some shaders/modern features too so the renderer is not lacking as much as you may think, i stated sometimes that it's an old renderer on steroids. The thing that ultimately killed the old branch was that localization feature, that part is very incomplete/hacky there. And the several refactorings, the latter being massive. Also there's a more modern alternative to the old backends made by dpJudas, the old LZDoom still has even DirectDraw.

[dpJudas]

The original plan with the softpoly backend was to also support a pure 8-bit path.

From what I can tell, the hardware renderer interface should actually be fully capable of doing colormap light shading if only the active colormap is also passed to FRenderState.SetSoftLightLevel. From there the backend could use the information combined with 8-bit textures to generate a look more or less identical to the zdoom software renderer. I just never found the motivation to actually implement this.

[mjr4077au]

The original plan with the softpoly backend was to also support a pure 8-bit path.

From what I can tell, the hardware renderer interface should actually be fully capable of doing colormap light shading if only the active colormap is also passed to FRenderState.SetSoftLightLevel. From there the backend could use the information combined with 8-bit textures to generate a look more or less identical to the zdoom software renderer. I just never found the motivation to actually implement this.

I'd be pretty keen on this if you ever did find the motivation, I was a software renderer holdout for a long time and have really only moved to the hardware renderer because I wanted consistent performance on my new 144Hz monitor.

[drfrag]

I just never found the motivation to actually implement this.

Interesting, if you ever decide to implement it i'd certainly made 8 bit softpoly the default render mode in LZDoom.