dsda-doom source port [v0.24.3]

[HackNeyed]

2 hours ago, kraflab said:

You can't set comp_ledgeblock in cl11 because it doesn't exist.

 

Well yeah I figured it would be completely ignored but I like to test just in case it wasn't somehow.

 

2 hours ago, kraflab said:

Are you sure about that behaviour?

Not a 100% sure. Can't disprove a negative and all that but after several attempts on each setting a convincing pattern emerged. They only ever fell under the conditions I outlined.

 

EDIT: Yeah @Gregor on the previous page agrees with it using a clever test.

Edited October 24, 2021 by HackNeyed
Edit2: more clarity that yeah I'm pretty sure.

[HackNeyed]

Ok, @kraflab checking in Woof ( @fabian ) complevel 21 I find that setting comp_ledgeblock 0 and comp_dropoff 0 I could knock the chaingunner over while alive. However, setting EITHER one to ON while leaving the other OFF I could NOT knock over the chaingunners. They BOTH had the same effect when separately enabled/disabled. That seems different from DSDA-Doom.

 

Then at complevel 11, again in Woof it was the same as above. It seems BOTH settings had to be off to push a chaingunner over. If EITHER one was ON then it wouldn't happen. As you said comp_ledgeblock isn't supposed to exist in complevel 11 and I know Woof isn't your port but here it is acting oddly as well. I could be missing something and if so I'm sorry but it looks like some investigation is needed.

[rfomin]

40 minutes ago, HackNeyed said:

However, setting EITHER one to ON while leaving the other OFF I could NOT knock over the chaingunners. They BOTH had the same effect when separately enabled/disabled.

Yes, in Woof comp_ledgeblock and comp_dropoff are essentially the same in this case. This was in the original MBF code, which was modified in PrBoom to fix the old VRACK2 demo, but this demo works fine in Woof without this fix, and I decided to keep the original code.

[entrywayy]

Hello,  

I am trying to set DSDA Doom up for the first time, everything is fine so far, just the mouse feels really, really off for me. Fells like kind of negative acceleration and pretty damn huge input lag. I don't have this problem in any other game. Other Sourceports also work flawlessly. Any Ideas what could cause this?

Edited October 24, 2021 by entrywayy

[Valboom]

14 minutes ago, entrywayy said:

Ciao,  

Sto cercando di impostare DSDA Doom per la prima volta, tutto va bene finora, solo il mouse mi sembra davvero, davvero fuori. Sembra una specie di accelerazione negativa e un input lag piuttosto dannatamente enorme. Non ho questo problema in nessun altro gioco. Anche altri Sourceport funzionano perfettamente. Delle idee che cosa potrebbe causare questo?

Have you tried disabling vsync? also try turning off mouse acceleration on Windows.

Edited October 24, 2021 by Valboom

[entrywayy]

Yes, i have Vsync always off, using Gsync. Doesn't matter if I have Gsync off or on, same problem. Mouse accel on Windows is off. I am pretty clueless about this issue right now.

[GoneAway]

@Gregorcould you make a small test wad and record a demo in mbf21 that plays back differently in woof and dsda-doom and post it? I need to figure out why it's different 😄

[GoneAway]

1 hour ago, entrywayy said:

Hello,  

I am trying to set DSDA Doom up for the first time, everything is fine so far, just the mouse feels really, really off for me. Fells like kind of negative acceleration and pretty damn huge input lag. I don't have this problem in any other game. Other Sourceports also work flawlessly. Any Ideas what could cause this?

Any chance you use "enhanced pointer precision"? Iirc that affected prboom+ at some point but not dsda-doom, so it might feel like there's a negative acceleration by contrast. But input lag I'm not sure about. If you're playing fullscreen you could try messing with the exclusive fullscreen options.

[HackNeyed]

1 hour ago, entrywayy said:

Hello,  

I am trying to set DSDA Doom up for the first time

...

Other Sourceports also work flawlessly. Any Ideas what could cause this?

 

Have you tried PrBoom-Plus+UM? It's what DSDA-Doom is based on. If your mouse problem is also in that port or if its fine in that port could help narrow down. I know DSDA-Doom's mouse handling was changed/improved so it might feel a bit off but it shouldn't lag. Unless maybe its the Uncapped Framerate? Try disabling it on the first page of the General section in options.

[entrywayy]

I have the same Issue with PrBoom Plus UM. I tried the different Settings regarding fullscreen modes, nothing really chagend. Still pretty massive Input lag. My Fps are capped at 167 (170hz Monitor). Also just rand GzDoom and the mouse feels perfectly fine there. Really curious what could cause that :/

[Redneckerz]

On 10/23/2021 at 12:41 AM, MechanicalSanity said:

well yes. I agree. But, in this case, this is the closest we can get (as far as I can tell) to getting the original intended music on PRBoom Plus and DSDA Doom. At the very least, it would be nice to be able to select it as an option through the menu. 

Simply not possible because;

• Size.
• Licenses.
• You could easily add it yourself, but then its a user (custom) thing.

[HackNeyed]

4 hours ago, kraflab said:

make a small test wad and record a demo in mbf21 that plays back differently in woof and dsda-doom and post it?

 

Hey @kraflab maybe I can help. There are 4 files in my attached zip. A fall.wad test map and an options.lmp with comp_dropoff 1 and comp_ledgeblock 0. Using these 2 files I made 2 recordings where I kill the Cyberdemon. If the demo ends with the Cyberdemon alive it has desynced. I used the commandline "engine -warp 01 -complevel 21 -file fall.wad options.lmp -record name"

woof-dead-fall.lmp
Recorded and played back in Woof the Cyberdemon only falls off once it is dead.
When played back in DSDA-Doom the Cyberdemon falls off but walks around the left side still alive.

 

dsda-alive-fall.lmp
Recorded and played back in DSDA-Doom the Cyberdemon falls off while still alive so I move around to kill it.
When played back in Woof I desync running around shooting at nothing and getting shot at because he didn't fall.

 

fall-options.zip

 

EDIT: Ok it is really late here and I should be sleeping so I hope I'm not messing something up.

 

I've repeated the test but swapping options.lmp to comp_dropoff 0 and comp_ledgeblock 1 and using complevel 11. Each demo I killed the Cyberdemon while recording. The demo recorded in DSDA-Doom "dsda11.lmp" plays fine in DSDA-Doom and Woof. The Cyberdemon falls off alive and I go after him killing him.

 

However @fabian @rfomin might want to know that the demo recorded in Woof "woof11.lmp" does not playback how I recorded it. The Cyberdemon never fell off while recording and I killed it on the pillar I swear. Yet both engines play the demo back exactly the same wrong way with the Cyberdemon falling off and shooting at me until the demo ends. Attached are the fall.wad, modified options.lmp and 2 demos. The "woof11.lmp" is actually the second one I made where I do a little spin at the end of the demo to have a look around after the desync I knew was going to happen.

 

fall-test11.zip

 

Edited October 24, 2021 by HackNeyed

[rfomin]

2 hours ago, HackNeyed said:

However @fabian @rfomin might want to know that the demo recorded in Woof "woof11.lmp" does not playback how I recorded it. The Cyberdemon never fell off while recording and I killed it on the pillar I swear. Yet both engines play the demo back exactly the same wrong way with the Cyberdemon falling off and shooting at me while its still alive.

You are correct, I forgot to reset the MBF21 comp options for the demo recording in the case of complevel 11. Thanks for the investigation and for the test WAD. If you're interested, I can send you the fixed beta version of Woof.

Wait, I was confused by the auto-incrementing of the demo names, I can't actually reproduce that. It's pretty late here too :) The problem is probably the OPTIONS lump, it should ignore the comp_ledgeblock for сomplevel 11. I'll investigate more tomorrow.

Edited October 24, 2021 by rfomin

[GoneAway]

From woof:

boolean ledgeblock = comp[comp_ledgeblock] &&
                     !(mbf21 && thing->intflags & MIF_SCROLLING);

if (comp[comp_dropoff] || ledgeblock)
{
  if (tmfloorz - tmdropoffz > 24*FRACUNIT)
	return false;                      // don't stand over a dropoff
}

From dsda-doom:

dboolean ledgeblock = comp[comp_ledgeblock] &&
                      !(mbf21 && thing->intflags & MIF_SCROLLING);

if (comp[comp_dropoff] || ledgeblock)
{
  // e6y
  // Fix demosync bug in mbf compatibility mode
  // There is no more desync on v2-2822.lmp/vrack2.wad
  // -force_no_dropoff command-line switch is for mbf_compatibility demos
  // recorded with prboom 2.2.2 - 2.4.7
  // Links:
  // http://competn.doom2.net/pub/sda/t-z/v2-2822.zip
  // http://www.doomworld.com/idgames/index.php?id=11138
  if (
    (
      ledgeblock ||
      !dropoff ||
      (
        !prboom_comp[PC_NO_DROPOFF].state &&
        mbf_features &&
        compatibility_level <= prboom_2_compatibility
      )
    ) &&
    (tmfloorz - tmdropoffz > 24*FRACUNIT)
  )
    return false;                      // don't stand over a dropoff
}

The prboom_comp part you can ignore, that's to account for an error in old prboom versions. Woof is missing the "ledgeblock || !dropoff" condition.

[Gregor]

7 hours ago, HackNeyed said:

dsda-alive-fall.lmp
Recorded and played back in DSDA-Doom the Cyberdemon falls off while still alive so I move around to kill it.
When played back in Woof I desync running around shooting at nothing and getting shot at because he didn't fall.

Trying to play back either dsda-alive-fall.lmp or woof-dead-fall.lmp in either DSDA or Woof i'm getting "encountered unknown mbf21 compatibility options". I can't play them back no matter the settings. What am i missing? The dsda11.lmp and woof11.lmp play back fine.

[HackNeyed]

7 hours ago, rfomin said:

You are correct, I forgot to reset the MBF21 comp options for the demo recording in the case of complevel 11. Thanks for the investigation and for the test WAD. If you're interested, I can send you the fixed beta version of Woof.

Wait, I was confused by the auto-incrementing of the demo names, I can't actually reproduce that. It's pretty late here too :) The problem is probably the OPTIONS lump, it should ignore the comp_ledgeblock for сomplevel 11. I'll investigate more tomorrow.

 

Sorry I was trying to keep the lump separate and editable for testing but I just left it as a bit of a juggling act. I've embedded the options lump with dropoff 0 and ledgeblock 1 into fall11.wad and made the following recording using this command on linux "./woof -warp 01 -complevel 11 -file fall11.wad -record fall11demo" While recording the Cyberdemon never falls and dies on the platform but when I play back "./woof -file fall11.wad -playdemo fall11demo.lmp" he falls off and is still alive at the end. Both files are in the zip fall11.zip

 

36 minutes ago, Gregor said:

Trying to play back either dsda-alive-fall.lmp or woof-dead-fall.lmp in either DSDA or Woof i'm getting "encountered unknown mbf21 compatibility options". I can't play them back no matter the settings. What am i missing? The dsda11.lmp and woof11.lmp play back fine.

 

That's because I'm on linux and often compile the latest github code for play and testing. There was an issue with Doom E2M7 that needed an update to the MBF21 spec to bypass. My demos include the new flag but an older compile will abort because it sees an unknown flag.

[Gregor]

16 minutes ago, HackNeyed said:

That's because I'm on linux and often compile the latest github code for play and testing. There was an issue with Doom E2M7 that needed an update to the MBF21 spec to bypass. My demos include the new flag but an older compile will abort because it sees an unknown flag.

Ah, i see. Thanks for the clarification.

[HackNeyed]

For those following along or passing by later @rfomin (Thanks!) has fixed things in github already. My fall11.wad/options.lmp with ledgeblock 1 no longer causes a desync when recording in Woof.

[L0l1nd3r]

On 10/22/2021 at 2:17 AM, Kappa971 said:

In my case a restart of the game only fixes the problem for a few seconds, I'm not sure but I think clicks only show up with certain sounds... for example, I remember the continuous sound of moving walls that creates audible clicks or the sound when scrolling through menus.

Does stuttering happen to you too?

I must have totally glossed over the Sound Blaster Z part of your post. I have one too and do occasionally get clicks in audio, not just in dsda and prboom, but any game. I usually go into the SB-Z control panel and restore the defaults, then reset to my liking.

[Kappa971]

46 minutes ago, L0l1nd3r said:

I must have totally glossed over the Sound Blaster Z part of your post. I have one too and do occasionally get clicks in audio, not just in dsda and prboom, but any game. I usually go into the SB-Z control panel and restore the defaults, then reset to my liking.

No, in my case in the other games I have no problems (apart from IDTech4 games with EAX active I hear some static noises, but this is probably a compatibility problem between these games and today's Creative/OpenAL drivers), only in DSDA-Doom/Prboom-plus and I can assure you that it only happens in some of the sounds, as if some sort of resampling of the sounds is done and in some this causes clicks. It is not the Windows mixer as it is set to 48khz as DSDA-Doom so it should not resample, nor SBX of the Sound Blaster Z control panel (I disabled everything and the clicks are still present).
I can't say 100% but I think it happened even before I owned the Sound Blaster Z

Edited October 28, 2021 by Kappa971

[Kappa971]

In my opinion certain problems should be reported in github otherwise they risk being lost among the various messages, but unfortunately, in the case of DSDA-Doom, it is not possible :(

[fabian]

6 hours ago, Kappa971 said:

It is not the Windows mixer as it is set to 48khz as DSDA-Doom so it should not resample, 

Doom's own sounds are stored with 11025Hz sample rates, so you should try setting your windows mixer to 44100Hz so you end up with an integer factor. 

[Kappa971]

6 hours ago, fabian said:

Doom's own sounds are stored with 11025Hz sample rates, so you should try setting your windows mixer to 44100Hz so you end up with an integer factor. 

I set the Windows mixer to 16bit 44100hz, I also tried 24bit 44100hz and DSDA-Doom at 44100hz but the problem remains. The sounds in which I notice the clicks are: the sound of moving walls, the sound while scrolling through the menu, the sound of the machine gun.

[Catoptromancy]

I had clicks too, but updated my distro and they are gone.

 

Clicking sounds feel sdl related. Do other ports with same exact revision of sdl also click. If there is another port using sdl without clicks, but a slightly different version can try swapping in that dll. There has been a couple revisions of sdl2 in the last couple years.

 

Had a similar issue a couple years ago, swapping sdl dlls to get smoother mouse. 

 

Edit: Also, Clicks in other audio using programs tend to be buffer related. The "slice_samplecount" is adjustable in the cfg and related to buffer.

Edited October 29, 2021 by Catoptromancy

[GoneAway]

3 hours ago, Kappa971 said:

I set the Windows mixer to 16bit 44100hz, I also tried 24bit 44100hz and DSDA-Doom at 44100hz but the problem remains. The sounds in which I notice the clicks are: the sound of moving walls, the sound while scrolling through the menu, the sound of the machine gun.

How many sound channels are you using? Does it happen if you make a single sound in the menu or is it specifically while holding down a direction and stacking a bunch of sounds for instance? Try increasing the number of sound channels and see if it makes a difference.

[Kappa971]

3 hours ago, kraflab said:

How many sound channels are you using?

32 channels (default).

 

3 hours ago, kraflab said:

Does it happen if you make a single sound in the menu or is it specifically while holding down a direction and stacking a bunch of sounds for instance?

Going down and up very slowly in the menu, there are no clicks, instead going faster I begin to hear them. This would explain why it doesn't happen in all sounds but only in those that are played quickly (moving walls, machine gun, etc.). 

 

4 hours ago, Catoptromancy said:

Edit: Also, Clicks in other audio using programs tend to be buffer related. The "slice_samplecount" is adjustable in the cfg and related to buffer.

slice_samplecount is set to 512, I don't know what this setting does.

 

3 hours ago, kraflab said:

Try increasing the number of sound channels and see if it makes a difference.

It doesn't make me enter values greater than 32.

Edited October 29, 2021 by Kappa971

[GoneAway]

Does it happen in every complevel?

[Kappa971]

2 hours ago, kraflab said:

Does it happen in every complevel?

It happens with complevel 3 (ultimate Doom) and 11 (mbf) but I guess the others too.

 

I also tested on a laptop with Debian 11 and the problem is present here too, so it happens on both Windows and Linux.

Edited October 29, 2021 by Kappa971

[Theespressoman]

compiling seems to be borked on arch linux

Spoiler

/usr/bin/ld: CMakeFiles/dsda-doom.dir/MUSIC/portmidiplayer.c.o: undefined reference to symbol 'Pt_Time'
/usr/bin/ld: /usr/lib/libporttime.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [src/CMakeFiles/dsda-doom.dir/build.make:2878: dsda-doom] Error 1
make[1]: *** [CMakeFiles/Makefile2:187: src/CMakeFiles/dsda-doom.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

is the issue with portmidi?

the only thing i can think of is it being out of date,but the arch package is as new as it gets (last updated on the 27th)

id open a real issue,but those are disabled.

[GoneAway]

5 hours ago, esspressoman said:

 

/usr/bin/ld: /usr/lib/libporttime.so.1: error adding symbols: DSO missing from command line

A cursory google indicates you may have a problem with how you're linking things when you compile. Pt_Time is defined in porttime.h, which is correctly included in portmidiplayer.c.