LZDoom 3.88b 02/26 released

[Apeirogon]

Found a bug.
If you set opengl renderer and you videocard dont support opengl 2 after restart lzdoom it throw error "cant use opengl, returns back to doom renderer." and next run would be successful.
But if you leave doom renderer an switch softare canvas from d3d to opengl AND you videocard dont support opengl at all, lzdoom would always throw "cant use opengl, returns back to doom renderer." error until you delete ini file.

[drfrag]

Fixed but GZDoom 3.3 didn't fall back to the software renderer. BTW the GL software canvas requires GL3.

[SyntherAugustus]

So I have the splitscreen version working fine but one big problem: The controller buttons are shared! (Player one's fire button also makes player two fire, etc). Will there be a fix for this?

This is using two PS4 contollers.

[drfrag]

It's not a bug i only allowed joystick input in the background, you need a different config for each player hence different folders. For two controllers is trickier (i've only tried with keyboard/mouse + 1 controller) and besides configuring the buttons you'll need to set the axes to none for the other player for each controller.

[SyntherAugustus]

I was successfully able to set separate axes for the controllers, but it looks like in order to have two controllers working buttonwise I need to emulate a keyboard with one of the controllers. Otherwise both players use each others actions. Perhaps a "Focus Certain Joystick" feature might help?

[drfrag]

No, seems ZDoom never actually supported more than one joystick. Ouch! There was only one player after all.
You can set axes for different joysticks but not the buttons, i still don't know if this is a bug or was never implemented.
Now i need to add support for setting the buttons for different controllers, hope i'm up to the task. As long as there's something for copy-pasta there should be no problem. If not expect one of those need help... threads.

[site]

Hadn't messed with sector light modes in a while cuz I usually play in software, but I've been playing going down in ogl cuz I was getting some low fps in software renderer at times and hit map15 and noticed that it looked bright, like light amp goggle fullbright bright. So I went into options and saw it was set to "Vanilla". Guessing my computers ogl version is too old to support it, which is fine, from what i hear that's shader dependent and shouldn't work on old hardware, but was flipping through the modes and "Software" isn't listed? Wasn't sure if that was intentional, but just checking that "Legacy" would be closest to the software renderer lighting out of the remaining choices since "Software" isn't available.

[Graf Zahl]

Actually, 'Legacy' is one of the least faithful lighting modes, it was added to replicate the OpenGL renderer of the Doom Legacy port.

If you do not get "Software" listed it most likely means your hardware has no good shader support. You'll have to make a compromise then. In order of decreasing faithfulness the light modes can be ordered as:

Vanilla >> Software >> Doom >> Dark >> Legacy >> Standard. The latter two use a very different lighting equation and are not to be considered faithful at all, they do not even approximate the original lighting mode.

[dpJudas]

Hmm that actually gives me an idea. Maybe we should change the UI for the light mode to look like what you just drew here? If its presented as a faithfulness scale like that the user will get a much better idea about what he's choosing between.

[drfrag]

It was a bug, something i overlooked when i ported the feature. Both software modes are not supported without shaders and should not appear in the menu on GL2.
May be adding an option to autodetect the hardware and change settings accordingly would be interesting (for a shitty display on non nvidia GL3 hardware).

Regarding the gamepad issue i've added support to up to 4 DInput joysticks at the same time for fake splitscreen. The buttons are somewhat shared tough and with more than 32 per device they will overlap as before and you'll get wrong labels. However i've added new buttons for axes and POVs.
Until now you could set the axes for different joysticks but not the buttons, the same events were sent for all the devices and there weren't button labels for different joysticks.
https://github.com/drfrag666/gzdoom/com ... 31bda8056d

[site]

Oh huh, never realized "Software" was also shader based. Thanks for the tips!

[sedrosken]

I'm a bit confused... the GitHub repo says it supports non-SSE2 CPUs, but the build I downloaded just crashes on my XP machine (Tualatin 1.4GHz, Ti4200, XP USP4/latest non-SSE2 updates). Which is it? Do I have to compile it myself to get it to run on SSE1-only CPUs? Sorry if this question has been asked and answered before. I tried to comb through the pages of replies but I didn't see anything -- I may have just missed it.

[drfrag]

LZDoom can be compiled without SSE2 on windows but the release requires it. I tested it long ago on an Athlon XP and a P3 and it worked, it should still work. But the sound libraries need also to be compiled without SSE2. If there's enough demand i might do a non SSE2 release.
BTW i've noticed that the 64 bit build cannot be compiled on VS 2015 anymore after the Asmjit update.

[sedrosken]

Eesh. Looking at the compilation guide it's probably a lot simpler than it seems but it also looks like a lot more than what I'm willing to undertake at the moment. It'll have to wait for a rainy day and even then I'll probably still screw it up somehow. Please do consider an SSE-only release! Or even just throwing the build you made to test up somewhere, I'm not picky... Until then, I'm probably just going to keep running GZDoom 1.8.03 on there. Unfortunately that has no support for the Adventures of Square IWAD that I was hoping to play on there. Loads up but dies on DamageTypes from what I can see. I'll leave it at that.

[Graf Zahl]

I understand your frustration, but you have to understand that with such old hardware you are part of a tiny, tiny minority.

We could do all we wanted here, the reality is that no software out there really cares for pre-SSE2 CPUs anymore, the market share of such old hardware is simply too small.
This means that we'd have to make sure that any library we use comes in a non-SSE2 compatible version and that's really easier said than done, because GZDoom and LZDoom need 4 externally built DLLs for their sound system, and all 4 of them needed to be rebuilt without SSE2 support to make it happen.

If it was just flipping a switch in the compiler, there'd be little effort providing a build that supports older CPUs - what we cannot do is making it the default, because it'd compromise the true color software renderer which heavily depends on SSE2 features that cannot be used in compatibility mode.

That said, Adventures of Square should work with early GZDoom 2.x builds, SSE2 only became mandatory around 2.3, I think.