LZDoom 3.82 'rogue' 07/19 released

[Rachael]

It's a bad merge of "Add "neutral" gender option and better obit formatting " somehow but there was no conflict. The 3.51 beta was not affected.
I'll investigate it. Setting the gender to object works, strange.

Is there any way that I can help you? Do you remember the conflicts you had with that merge?

[drfrag]

Thanks, if you could help i'd really appreciate it. Technically it's not a bad merge, there weren't any conflicts. The code is pretty much the same. Following s_advsound.cpp history the only difference is that "Removed all superfluous #include's" is not there.
This is not easy to debug, i've only managed to see that listidx = 65535 when gender is not OBJECT (else it's 3) and in static int S_LookupPlayerSound the engine enters in if (listidx == 0xffff) and if (g == GENDER_MAX).
I've noticed that there are three versions of S_LookupPlayerSound, i'm referring to the one defined in line 1768.

[Rachael]

Unfortunately... I know next to nothing about the sound system. When I offered to help I thought you were referring to that specific commit - something I did know a bit about.

Is listidx the same in both source ports? Have you debugged GZDoom itself with this issue? I will say, it sounds almost as if the references between "male" and "female" were completely broken in that commit. But why it reverts to Doomguy screams and grunts, is pretty strange.

[drfrag]

I've checked the files in that commit with difmerge at that point and the only difference between LZDoom and the vintage build is a few includes, not that all of them are really needed. The changes to s_advsound.cpp look very innocent (and to all those files) and i'm almost sure the problem is not in the sound system at all. Must be something else but no idea of what happens. The references to listidx are the same. It's essentially the same code.

[Rachael]

I've tried to look at this but nothing I see is indicating to me that there should be any issue. Whatever the issue is, it's buried pretty deep.

[drfrag]

Thanks again for looking into it. That or it's a pretty silly thing somehow related to the includes/different layout.
Looks like a brute force code analysis is in order (DiffMerge+Blame), shouldn't take too much.

[drfrag]

I've noticed that Heresy II (tested with Doom II, it's for Heretic) works well selecting the baron player.
Why does junoplayer appear twice? That's the player class twice and not the gender. Is gender optional? Is this a bad definition or a custom gender?
https://zdoom.org/wiki/SNDINFO

Code: Select all • Expand view

$playersound   baron   male   *death      dsbrsdth

$playersound           junoplayer    junoplayer    *death       death

Edit: i see that if gender is not identified the default is object now and not male (d_netinfo.cpp), that could be the problem. But i don't know why it works in GZDoom.

[drfrag]

I've pushed a fix here:
https://github.com/drfrag666/gzdoom/com ... 6bb82afd83

I've managed to reproduce the issue with the vintage build (recent devbuild), remember that 3.60b2 is ahead 3.6.0.

[Rachael]

Cool.

Thank you.

[drfrag]

You're welcome. I made the same mistake and compared with 3.6.0_legacy, also i should have checked the mod better.
You can add me as remote and cherry-pick the fix if you want, It's not in the legacy branch yet since i'm merging a lot of stuff from the asmjit branch and i haven't compiled yet (it would take a lot of time). I couldn't merge directly or else i would get a fake history.

[drfrag]

I've released a new beta with the fix (see first post). While technically it's not a bug (it's a mod side one) and it's a minor thing i've pushed a fix since there must be a fallback default for the sound class gender when it's not properly defined and that must be male not other since that's the default value for the gender cvar (doomguy it's not an object). So please tell Impie it's a problem with the mod itself.
Of course the dither shader had to go so no more intel fixed versions (not needed anymore).
This delayed beta is in sync (is that term even correct?) with GZ master as of 11/29 to clarify things.

I could not port the recent SSE optimizations to the poly renderer (and the poly renderer is very important in LZDoom).
There was a crash in resolutions > 640 with "removed the 8x8 block drawing code from softpoly" related to sky caps, of course i could try to fix that. But then "change DrawSpanOpt32 to render a scanline in multiple steps" causes a black screen problem with broken geometry in the menu, it only works after starting the software renderer first after engine launch. That's why it requires "change the software renderer to render to a DSimpleCanvas like the old D3D9 target did. Then use the drawer threads to memcpy the result to the PBO" which itself requires some things in "added a software scene drawer to the GL renderer".
Just in case someone is interested, as usual any hints/help would be appreciated.

Also i've pushed a lot of stuff for the legacy build, looks like Graf is working on the engine full time. Does he even sleep? So i'm getting close but still not there.

[dpJudas]

Are you talking about a crash with sky caps in GZDoom itself, or in the attempt to backport it?

[drfrag]

Sorry i meant > 640 and it happens only with the old D3D and OGL backends, the vintage build runs fine. I reverted that commit but the main problem is the black screen thing.

[drfrag]

I released beta 4 yesterday just to fix the glowing flats bug, GL 2 cards were not affected.

[kondoriyano]

i found some issue when playing with this music jukebox
viewtopic.php?f=46&t=49073
its like the music loop is interrupted