LZDoom 3.88b 02/26 released

[drfrag]

I plan to release 3.85 tomorrow, there have been several delays mainly due to a a crash with the 32 bit version after the OpenAL update. For now i'm sticking to 1.19.
I've added a last minute feature (support for several control layouts) and it has turned out to be problematic so i've uploaded another test build here:
https://devbuilds.drdteam.org/lzdoom/lz ... 037fcd.zip

[drfrag]

I've just released 3.85. This will be the last version supporting WinXP.

[Graf Zahl]

This will be the last version supporting WinXP.

So, did it become too much of a hassle after all?

[drfrag]

Of course not but Rachael wants to remove it.
Edit: but most likely it will soon anyway.

[Rachael]

So, did it become too much of a hassle after all?

Of course not but Rachael wants to remove it.

Probably dealing with me bitching about it constantly became a hassle.

That being said, I was just getting sick of all the extra considerations that had to be made for Windows XP. If something still works on XP I don't see any reason to go out of the way to actually break it - however - I also simply don't see any reason to put in any extra effort to keep it working on XP either. If it breaks on its own in XP, though - that's life, and I really think the effort towards fixing it is counter-productive in the bigger picture.

And past posting indicates that even if it wasn't a "major" hassle to keep things working in XP, it was still somewhat of a hassle in any case.

[drfrag]

Well the real challenge will be to keep it running on 32 bit, v141_xp is the last toolset to support XP and when newer language features are required it will be over for XP for sure. But right now OpenAL 1.20 won't run on XP and for future versions that's unknown, i'm not going to create a custom OpenAL build in any case.

[TDRR]

I tried playing on paletted software softpoly, but there's a very weird issue with the weapon sprite, which has various "scanlines" flickering on it unless I disable r_multithreaded (And then it runs very slow so that's not really a solution).



This doesn't only happen over other sprites, it also happens with just the map itself.

I have heard that LZDoom will apparently change it's goal so not sure if this bug report even matters anymore, but here it is anyways.

[drfrag]

But since when? Latest release or a devbuild? For me it works well, have you tried setting it to 2? It might be system specific (cpu), didn't you made some related report some time ago?

[TDRR]

But since when? Latest release or a devbuild? For me it works well, have you tried setting it to 2? It might be system specific (cpu), didn't you made some related report some time ago?

This only started happening with LZDoom 3.85, I'm using the 64-bit build and I tried setting r_multithreaded to 1 and 2 but both give this same issue. I'm running a Celeron N2805 1.4GHz, and it did have issues with r_multithreaded detection back then, but this has been fixed a long time ago already for me.

[drfrag]

Does it happen with just the doom iwad or with that mod? Which resolution?

[TDRR]

Does it happen with just the doom iwad or with that mod? Which resolution?

640x480. It doesn't happen with the Doom IWAD, but I didn't test that earlier because I thought there wasn't really any way it would make a difference, but it does for some reason, strange.

I'm also using the D3D9 canvas but this happens too with OpenGL, so it's probably an issue with softpoly itself.

[drfrag]

And where's the mod?

[TDRR]

https://www.doomworld.com/forum/topic/1 ... w-version/

[drfrag]

Sorry but this is clearly a can't fix case. The issue appeared after i reverted "- removed the 8x8 block drawing code from softpoly" and it was already present in 3.60 beta so it's very old. I can't revert that revert, there were no conflicts but with that commit softpoly crashed at resolutions higher than 640, it's a strange crash (triggers a breakpoint) and seems sky related and only happens here without the 2D refactor. Unfortunately it's not a bad merge and i can't do a proper fix myself obviously.
At least it's a minor thing and for me even whithout r_multithreaded the mod it's playable (50 fps) and this is lowend. I don't know what's so special about those weapon sprites, they are just doom graphics. It only affects weapon sprites in that mod and in truecolor mode it's the same. Softpoly already had serious issues in GZDoom itself and there were other sky related crashes. So can't fix.

Code: Select all

>	lzdoom.exe!_free_base(void * block) Line 105	C++
 	[Inline Frame] lzdoom.exe!FBitmap::Destroy() Line 100	C++
 	[Inline Frame] lzdoom.exe!FBitmap::{dtor}() Line 95	C++
 	lzdoom.exe!FTexture::GetSkyCapColor(bool bottom) Line 904	C++
 	[Inline Frame] lzdoom.exe!PolySkyDome::RenderCapColorRow(PolyRenderThread *) Line 117	C++
 	lzdoom.exe!PolySkyDome::Render(PolyRenderThread * thread, const Mat4f & worldToView, const Mat4f & worldToClip) Line 91	C++
 	lzdoom.exe!RenderPolyScene::Render(PolyPortalViewpoint * viewpoint) Line 104	C++
 	lzdoom.exe!PolyRenderer::RenderActorView(AActor * actor, bool dontmaplines) Line 173	C++
 	lzdoom.exe!PolyRenderer::RenderView(player_t * player) Line 79	C++
 	lzdoom.exe!FSoftwareRenderer::RenderView(player_t * player) Line 180	C++
 	lzdoom.exe!D_Display() Line 841	C++
 	lzdoom.exe!D_DoomLoop() Line 1093	C++
 	lzdoom.exe!D_DoomMain_Internal() Line 2872	C++
 	lzdoom.exe!D_DoomMain() Line 2884	C++
 	lzdoom.exe!DoMain(HINSTANCE__ * hInstance) Line 963	C++
 	lzdoom.exe!wWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * nothing, wchar_t * cmdline, int nCmdShow) Line 1290	C++

[drfrag]

I've uploaded a new vintage devbuild, it was not affected by this problem. Also i've removed win10 compatibility from the manifest to address the bug with some old intel drivers (OpenGL not accelerated error).
https://devbuilds.drdteam.org/gzdoom-vi ... ae30487.7z