dsda-doom source port [v0.24.3]

Win32 build of dsda-doom 0.24.0

https://github.com/RamonUnch/dsda-doom/releases/download/v0.24.0/DSDADoom-0.24.0-win32.7z

HOLY HELL, why there are suddenly 33 different gamma levels? And why it was so high by default?

Oh right, I missed something in the patch notes. The opengl light modes have been reduced to shader mode (best look right now) and the legacy original mode. These will be further improved upon with xaser's rewrite. Previously the default was quite bad, and the extra options didn't add much except extra complexity. I wanted to provide a more natural-looking default, and kept the legacy mode for compatibility reasons (and to have a mode where gamma doesn't affect the display).

So, I turned vsync and the fps limit off, but I only noticed a performance boost with the OpenGL mode, especially with triple buffering turned on.  I have noticed more often that it seems like the software choppiness is related to how high the horizontal sensitivity is, with mine at 30 and fine sensitivity at 40. For example, I focused on the pistol when quickly turning left and it didn't seem to be affected, but when I focused on anything in the surroundings, it looked and felt choppy. Like the frames weren't keeping up with the movement, if that makes any sense. But doing the same thing in the OpenGL renderer and Woof didn't replicate it. At this point, I'm starting to wonder if my laptop just doesn't like DSDA's software mode as it is now. 

I had got 2 crashes when adjusting the settings, and Event Viewer say something about BEX64 and dxcore.dll (if that help).

After that, I managed to get the settings I was aiming for, and didn't get more crashes.

What setting did you change when it crashed?

Video settings: from windowed to full screen, screen size to 1080p, and from Software to Opengl.

I'm not sure how to best describe the particulars here, but based on my testing, I feel that there's some flaw in the Parallel Same-Sound Limit option that can prove unintentionally detrimental to gameplay. It's easiest to simply demonstrate the issue in-game, and I came up with two config setups to illustrate this:

1. Sound channels = 8 (same max as the vanilla DOS executable), Parallel same-sound limit = 0
2. Sound channels = 32, Parallel same-sound limit = 8

I made a custom map to create a reproducible scenario in which the maximum limit for a single sound is consistently hit (in this case, the Revenant sight cry) with both the aforementioned settings. Under this very controlled test scenario, I'd imagine both configs would sound comparable. However, that doesn't turn out to be right. Here's a video with both cases recorded:

Note the test map allows me to travel to both sides of this long room populated with Revenants along the whole way. In the first config setup that just has the 8 channel sound limit, I can hear a blaring cacophony of Revenants when I punch the air regardless of which side of the room I'm on. However, in the second config setup with the increased sound channels but an enforced Parallel Same-Sound Limit of 8, the side of the room I alert the Revenants on has a dramatic effect on what's audible. At the player start side with the happy face, I hear maybe a few very distant Revenant cries when I punch the air. If I go to the other side with the anguished face and shoot, I hear the expected eardrum-destroying Revenant explosion.

I figure the engine is iterating through the monsters linearly when determining when the Parallel Same-Sound Limit is reached in a given time period. The issue here is that it seems the option can prioritize the sounds which are nearly inaudible, resulting in the possibility that a large group of alerted demons can be either near silent or utterly deafening.

It's not just the alert cries that can be affected, however. As an extreme stress test, I also tried this experiment in 100,000 Revenants. This is, of course, far beyond a normal use case, but you can hear that the prioritization of the parallel sounds renders the Revenant horde completely silent in the second test case, and even their actions like rocket explosions, punches, and death crackles are mostly wiped out too.

With the parallel sound limit, if the first 8 revenant cries happen to be at the far end of the map, that's all you'll hear, while with the sound channel management I think there's some sort of priority system and distance falloff (so inaudible sounds don't occupy channels) though I don't know how it works.

Edit: Maybe the dsda_BlockSFX check can be moved to after S_AdjustSoundParams so inaudible sounds don't get counted toward the parallel sound limit?

Also, to limit the volume of a large crowd of monsters waking up using the parallel sound limit, you'd probably want to adjust the "parallel same-sound window" (the number of tics looked at when counting how many times a sound has played) higher since monsters may start their cries at different tics. With it set to 1 you can get 8 cries playing on one tic, another 8 on the next, and so on, which still sounds deafening.

The parallel sound limit doesn't work anything like the sound channel limit. The channel limiter cuts things off and replaces sounds, whereas the parallel limit stops new sounds from kicking out the old ones. Accounting for volume before counting the sound is a good idea though, I'll have to experiment with it.

Is there list of console commands for DSDA somewhere? I don't know if it even serves the same purpose as the consoles in ZDoom or Eternity. I'm specifically looking for a way to reset the music each time i restart the map. In GZDoom and Eternity this can be done by binding the "stopmus" command to a key. Is there an equivalent for DSDA?

30 minutes ago, Gregor said:

Is there list of console commands for DSDA somewhere? I don't know if it even serves the same purpose as the consoles in ZDoom or Eternity. I'm specifically looking for a way to reset the music each time i restart the map. In GZDoom and Eternity this can be done by binding the "stopmus" command to a key. Is there an equivalent for DSDA?

You can find the commands in the patch notes when the console was added and spread out over other patch notes since then. But don't expect to find functionality on the level of ZDoom or Eternity for now. I think your best option for restarting the music is to use the IDMUS cheat code.

6 hours ago, Shepardus said:

You can find the commands in the patch notes when the console was added and spread out over other patch notes since then. But don't expect to find functionality on the level of ZDoom or Eternity for now. I think your best option for restarting the music is to use the IDMUS cheat code.

Well, IDMUS is of course exactly what i was trying to avoid. Oh, well. Maybe in the future something similar to stopmus is included. Thanks for heads-up!

Well, the function to restart the music - S_RestartMusic() - is already present in DSDA-Doom and Prboom-plus. To make what you want happen in the latter you may only need to edit the following section of g_game.c

//
// G_RestartLevel
//

void G_RestartLevel(void)
{
  special_event = BT_SPECIAL | (BTS_RESTARTLEVEL & BT_SPECIALMASK);
}

to

//
// G_RestartLevel
//

void G_RestartLevel(void)
{
  special_event = BT_SPECIAL | (BTS_RESTARTLEVEL & BT_SPECIALMASK);
  S_RestartMusic();
}

That section is absent from DSDA-Doom's g_game.c, though. Perhaps kraflab could point out what needs to be changed there.

On 2/8/2022 at 9:45 PM, Eddie 2077 said:

So, I turned vsync and the fps limit off, but I only noticed a performance boost with the OpenGL mode, especially with triple buffering turned on.  I have noticed more often that it seems like the software choppiness is related to how high the horizontal sensitivity is, with mine at 30 and fine sensitivity at 40. For example, I focused on the pistol when quickly turning left and it didn't seem to be affected, but when I focused on anything in the surroundings, it looked and felt choppy. Like the frames weren't keeping up with the movement, if that makes any sense. But doing the same thing in the OpenGL renderer and Woof didn't replicate it. At this point, I'm starting to wonder if my laptop just doesn't like DSDA's software mode as it is now. 

Could you please check out the latest PrBoom+ release and report if it also feels choppy for you? I have reverted its interpolation formula to the same one Woof! uses.

https://www.doomworld.com/forum/topic/106866-prboom-262-feb-11-2022/

6 hours ago, fabian said:

 

Could you please check out the latest PrBoom+ release and report if it also feels choppy for you? I have reverted its interpolation formula to the same one Woof! uses.

 

https://www.doomworld.com/forum/topic/106866-prboom-262-feb-11-2022/

 

I can in a bit, a Windows update is installing itself and I have to wait until it finishes so I have enough resources to run something like that. EDIT: I got it running anyway, the 15-bit renderer is the only one that had any lag for me. That renderer is also the only one I noticed looked software-ish.  I went through and did the movement test thing I was talking about, with and without modifying mouse sensitivity, and all but the 15-bit worked fine. 

Hmm, I'm still experiencing crashes. I just managed to replicate it a few times in a row. I'd boot up the game with the dsda-doom.wad and Cydonia.wad, that uses Plutonia as iWAD. I take a screenshot in the main menu and then try to start a new game on nightmare. Crash. Not 100% of the time, but surprisingly often. The pwad I used probably has no relevance, since I just achieved the same with Sunlust. And with Ultimate Doom IWAD.

I still use DoomLauncher to boot up DSDA or any other source ports (DSDA's the only one I use in practice, though), so I thought maybe it has something to do with that... but no: Launched DSDA from command line prompt with Doom2.wad as iwad (no pwads), took a screenshot in the main menu, crashed.

I still wonder if this is a sound-related issue. Similar crashes (I'm assuming same root cause) have occurred when taking screenshots mid-level, when I exit a level and the next one is starting, and on a rare occasion when an ambush hits and there are lot of sounds (revenants screeching, plasmas being fired). I guess starting the game from the main menu is a case of "starting the next level".

I haven't looked at the screenshot issue yet, so I wouldn't expect a fix in the present version. I'll take a look soon though.

@RHhe82 can you post your config file? It may depend on specific settings, so I'll need a reference.

16 minutes ago, kraflab said:

I haven't looked at the screenshot issue yet, so I wouldn't expect a fix in the present version. I'll take a look soon though.

 

@RHhe82 can you post your config file? It may depend on specific settings, so I'll need a reference.

Sure thing.

dsda-doom config file rhhe82.zip

I found a bug with MBF21 compatibility. The SSG is bugged when A_CheckReload detects less than two shells. I'm not sure exactly what the conditions are as they seem somewhat arbitrary, but when you run out of ammo it will lower the SSG and the next weapon is never raised, softlocking the player. I have boom weapon autoswitch set to 0 if that matters.

I know for sure that it happens when you're completely out of ammo for everything, and also when you only have bullets and the pistol (no chaingun).

2 hours ago, maxmanium said:

I found a bug with MBF21 compatibility. The SSG is bugged when A_CheckReload detects less than two shells. I'm not sure exactly what the conditions are as they seem somewhat arbitrary, but when you run out of ammo it will lower the SSG and the next weapon is never raised, softlocking the player. I have boom weapon autoswitch set to 0 if that matters.

Well, you learn something new about prboom+'s convoluted auto switching logic every day :^)

New build coming soon.

Updated to v0.24.1

Unfortunately, it seems that in the later complevels prboom+ added some logic that injects an invalid player weapon state (changing weapon without a pending weapon set). It gets around this by queueing a command that will set the pending weapon later, so that it fixes the state before it reaches the time when it needs to know what weapon to switch to. Since the state injection leads to undefined behaviour, we can't turn off the auto-toggle for the ssg (without breaking demo compatibility).

What's new:

• Added a first batch of cheats to the console (PBeGood4)
  • idchoppers, iddqd, idkfa, idfa, idspispopd, idclip, idmypos, idrate
  • tntcomp, tntem, iddt, iddst, iddkt, iddit, notarget
• Fixed ssg autoswitch in cl21

download

Win32 build of dsda-doom 0.24.1

https://github.com/RamonUnch/dsda-doom/releases/download/v0.24.1/DSDADoom-0.24.1-win32.7z

16 hours ago, Eddie 2077 said:

  I went through and did the movement test thing I was talking about, with and without modifying mouse sensitivity, and all but the 15-bit worked fine. 

Okay, thank you for checking! @kraflab have you seen the edit?

please make the program alt+f4 quit instantly instead of having a delay, thanks!

1 hour ago, LOD42 said:

please make the program alt+f4 quit instantly instead of having a delay, thanks!

You quit the game so often? If you're doing speedruns, there's a hotkey to restart the map from the beginning.

We called it the "Boss key" back then. It was meant to quit immediately: 

https://github.com/coelckers/prboom-plus/commit/9efa6051aa15f01335ef6432e872694272910c3f

5 hours ago, fabian said:

 

Okay, thank you for checking! @kraflab have you seen the edit?

I would need an explanation of why the change would fix anything, considering the existing changes in dsda-doom fixed various things for other people. The fact that it mysteriously doesn't work in 15 bit mode makes me skeptical it isn't even just a placebo.

Sorry to bother about the gamma thing again, but why when switching to OpenGL, it's automatically set to level 8?

@Eddie 2077 do you have the stuttering if you are watching a demo? There's an optimization I've had on my todo list related to some stuttering that could come from input handling, so I'm curious if you see problems when input isn't involved (e.g., when just watching demo playback).