dsda-doom source port [v0.24.3]

[GoneAway]

There have been some crashes reported lately, predating 0.23 as well.

 

Rayziik has had some while recording for Haste and has a debugger set up in the hopes of catching the next crash in action. Unfortunately, whatever this crash is doesn't appear to be reproducible with a demo, as I tried playing back the crash case 10k times without reproducing it 😅

 

As it doesn't appear to be super common, it's been hard to track down. If anyone wants to help out (and knows how to build dsda-doom and run it with a debugger), Rayziik's config is attached, and the wad in question was https://dsdarchive.com/wads/haste. I'm not sure if demo recording is essential, but if you're going to try to reproduce, I'd suggest recording map 1 with "-record has01m" and using in-game restarts for a consistent context.

 

Anyone who gets a crash backtrace for me wins a gold star 🙌

rayziik-dsda-doom.zip

[gwain]

I love this port just compiled it yesterday (it was so easy with the instructions included )

[imabitjelly]

I have an odd issue with both this port and PrBoom+ (apologies if this is not the right place to post this).

 

When using the "shaders" HW light mode, the gamma level feature uses the SDL hardware gamma functions. This messes up the colors on my monitor and makes them extremely washed out. Looking at the SDL source, it seems like SDL on Windows uses SetDeviceGammaRamp(), which Microsoft docs discourage because it interacts poorly with color calibration. I have a custom color profile added to my monitor, so maybe it's being bypassed by this function.

 

Has anyone else had this issue? Right now I have disabled hardware gamma in a fork of the code that I build locally. This workaround prevents the messed up colors but also makes the gamma levels do nothing so it's not a full solution.

[GoneAway]

New opengl lighting is coming soon courtesy of @Xaser

[RHhe82]

On 1/19/2022 at 11:07 PM, kraflab said:

There have been some crashes reported lately, predating 0.23 as well

Just an update if someone is trying to replicate the crash with debugger: It’s happened to me twice when taking a screenshot. First time I thought it had to do with me recording a demo at the same time a couple of days ago, but the second time occurred earlier this evening, trying to ITYTD-MAX Scythe MAP30 while not recording a demo, just taking a screenshot. It would play the telephone sound and then crash to desktop.

[blob1024]

thanks for the amazing job

out of curiosity I just tried it out and was easy to configure. what I am missing now is the timedemo to be working.

like in prboom i find msyelf at ease to duplicate the dsda/prboom exe and make "demorecording" and "timedemo" commands ouf ot them

but I guess the viddump files aren't inside the base zip.. am I right? demo correctly replayed with portmidi as well, but doesnt produce any video. do I have to look for the same files I have been using with prboom+ or something newer or more specific for this port was set up?

I love the auto-restart demorecording and the possibility to have time+kill counts together with status bar

[Shepardus]

On 1/22/2022 at 4:14 AM, blob1024 said:

thanks for the amazing job

out of curiosity I just tried it out and was easy to configure. what I am missing now is the timedemo to be working.

like in prboom i find msyelf at ease to duplicate the dsda/prboom exe and make "demorecording" and "timedemo" commands ouf ot them

but I guess the viddump files aren't inside the base zip.. am I right? demo correctly replayed with portmidi as well, but doesnt produce any video. do I have to look for the same files I have been using with prboom+ or something newer or more specific for this port was set up?

I love the auto-restart demorecording and the possibility to have time+kill counts together with status bar

The default commands used for viddump were changed. PrBoom+ used to use the x264, oggenc, and mkvmerge executables for video encoding, audio encoding, and muxing, respectively, but now the default is ffmpeg for all of them. You can get a build of ffmpeg.exe from ffmpeg.org, or check Daerik's guide which has a link to a copy of FFmpeg bundled with dsda-doom.

 

Alternatively, you can use what you have from PrBoom+ if you copy over the same executables (i.e. x264.exe, oggenc.exe, and mkvmerge.exe), and in dsda-doom.cfg, under "# Video capture encoding settings" copy the configs from your prboom-plus.cfg (specifically cap_soundcommand, cap_videocommand, cap_muxcommand, cap_tempfile1, cap_tempfile2, cap_remove_tempfiles, and cap_fps).

[msx2plus]

i was just clued into the "parallel sound" options and they're amazing, thank you for this!! could there be an option added that always prioritizes the most recent instance of the sound? ie. two copies of the sound can play at once, and when the third one plays, the first one that played gets cut off.

[GoneAway]

The crash is coming up in the software renderer, so you may want to use the hardware renderer until the next release if you run into issues fyi.

[GoneAway]

On 1/24/2022 at 6:45 AM, msx2plus said:

i was just clued into the "parallel sound" options and they're amazing, thank you for this!! could there be an option added that always prioritizes the most recent instance of the sound? ie. two copies of the sound can play at once, and when the third one plays, the first one that played gets cut off.

I think this would introduce unpleasant audio artifacts, although I'm not 100% sure. There's currently no tracking for what sound played when, so there'd need to be some reworking of the metadata for sounds.

[fabian]

20 minutes ago, kraflab said:

The crash is coming up in the software renderer, so you may want to use the hardware renderer until the next release if you run into issues fyi.

 

Does this mean you have found and fixed the cause for the crash?

[GoneAway]

1 hour ago, fabian said:

 

Does this mean you have found and fixed the cause for the crash?

I will tag you when I commit the fix. I don't really know the real cause right now, but my current guess is that some insane fucked up compiler optimization side effect allows an error to propagate into a crash in the renderer. It would explain why this has randomly surfaced despite no changes in the related code. Suffice to say there's a case where the BETWEEN function is executed as a no-op on an integer at runtime (more investigation ongoing though) 🙂

[fabian]

Ah, one of these bugs that vanish once you rebuild your binaries with "-O0" in order to debug it. 😉

[GoneAway]

26 minutes ago, fabian said:

Ah, one of these bugs that vanish once you rebuild your binaries with "-O0" in order to debug it. 😉

Yes exactly, we've been debugging with release builds because the debug ones don't crash 😁

[Ramon_Demestre]

I have a very specific request about screen scaling, let me explain my specific case:

I have a 4:3 monitor (old school) and I like to play with a resolution of 640x400. When I use the "non-exclusive" software mode, dsda-doom as well as prboom+ properly fills the whole monitor and renders exactly as intended (like crispy-doom). However on my machine I like to use the exclusive software rendering option because I get better performances this way (and it is helpful). My monitor stretches the 640x400 buffer to the full monitor rendering non-square pixels. However dsda-doom does not know this and assumes pixels are square on the screen and whatever settings I modify, I see black margins on the monitor sides and the image is stretched vertically using less than the full 640 pixels.

Of course the fix is to use 640x480, but I far prefer 640x400.

Note that the problem is exactly the same using 320x200, that is also stretched to 4:3 with non-square pixels on my monitor.

There could be an additional "FILL" scaling option or something, maybe I am missing a setting, but I could not find reading the .cfg file.

 

[GoneAway]

Could you post a photo of exclusive and non-exclusive just to make sure I understand the problem? 😅

[Ramon_Demestre]

Exclusive full screen 640x400, the problem is that the whole image is stretched to 4:3:

If my monitor was 16:10 then it would look fine, but

 

Nonexclusive fullscreen (monitor resolution is 1400x1050), looke good!:

[GoneAway]

Is it the operating system that decides how to display it in exclusive mode? I'm not really sure. There's also an aspect ratio correction in place for the classic resolutions. Maybe disabling this effect would cause the effect you're looking for?

    // [FG] aspect ratio correction for the canonical video modes
    if (SCREENHEIGHT == 200 || SCREENHEIGHT == 400)
    {
      actualheight = 6*SCREENHEIGHT/5;
    }
    else
    {
      actualheight = SCREENHEIGHT;
    }

 

[Ramon_Demestre]

Yes indeed if I comment out the special case, everything is as intended in exclusive full-screen mode:

    // [FG] aspect ratio correction for the canonical video modes
//    if (SCREENHEIGHT == 200 || SCREENHEIGHT == 400)
//    {
//      actualheight = 6*SCREENHEIGHT/5;
//    }
//    else
    {
      actualheight = SCREENHEIGHT;
    }

Exclusive mode, it looks "flat" here, but is actually rendered stretched to 4:3 on my monitor so it is perfect!

 

but looks wrong in non-exclusive mode (flat):

 

So I think this special treatment should be reserved to the non-exclusive mode? or it could be a separated flag?

I think that if someone uses the exclusive mode and 320x200 or 640x400, it means he wants a vanilla style behavior, where the monitor has to do the aspect correction instead of not using the full width of the frame.

Thanks a lot for your quick answer, I have my fixed build now

[Ramon_Demestre]

For me the fix "should" just be to check for the exclusive_fullscreen variable in software. This would also make it behave like the GL mode that does not do that and treat 640x400 and 320x200 like the software mode with this fix.

 

    // [FG] aspect ratio correction for the canonical video modes
    if (!exclusive_fullscreen && (SCREENHEIGHT == 200 || SCREENHEIGHT == 400))
    {
      actualheight = 6*SCREENHEIGHT/5;
    }
    else
    {
      actualheight = SCREENHEIGHT;
    }

 

[GoneAway]

Someone may still want the "stretched pixel" look in exclusive mode and not mind the bars. I guess I'll add an extra flag in some form.

[Ramon_Demestre]

8 hours ago, kraflab said:

Someone may still want the "stretched pixel" look in exclusive mode and not mind the bars. I guess I'll add an extra flag in some form.

I agree with you, however it appears that in opengl mode scaling behaves quite differently.

In gl-exclusive mode, dsda-doom always uses the full video buffer resolution, and never makes margins to compensate for aspect ratio. It works nicely with 640x400 for me but there is not the option to scale like it does in exclusive-software, so I guess it would be nice if you add a flag that it applies to both GL and software render.

[liPillON]

Hi everyone!

I've made a widescreen statusbar for Hexen and I'm facing some weird behaviour when testing it with dsda-doom.

Would anyone want to help me figure out if there's something wrong with the asset or with the engine?

I'm using dsda-doom 0.23 for windows (64bit)

 

I have observed this when using the software rendering:

- 1st run: my H2BAR lump is not loaded/displayed until I change the "statusbar and menu appearance" option

- 2nd run: the lump is again ignored until I change that option 

- all other runs: same as the second

 

When using the opengl renderer, the new lump is always loaded/displayed. 

 

Doom and Heretic do not have this issue, neither using the software nor the opengl renderer.

 

I've attached the three wad I've been testing.

I'd appreciate some feedback, thank you!

  

WS_Statusbars.zip

Edited January 28, 2022 by Delfino Furioso

[blob1024]

On 1/23/2022 at 1:48 PM, Shepardus said:

The default commands used for viddump were changed. PrBoom+ used to use the x264, oggenc, and mkvmerge executables for video encoding, audio encoding, and muxing, respectively, but now the default is ffmpeg for all of them. You can get a build of ffmpeg.exe from ffmpeg.org, or check Daerik's guide which has a link to a copy of FFmpeg bundled with dsda-doom.

 

Alternatively, you can use what you have from PrBoom+ if you copy over the same executables (i.e. x264.exe, oggenc.exe, and mkvmerge.exe), and in dsda-doom.cfg, under "# Video capture encoding settings" copy the configs from your prboom-plus.cfg (specifically cap_soundcommand, cap_videocommand, cap_muxcommand, cap_tempfile1, cap_tempfile2, cap_remove_tempfiles, and cap_fps).

the bat file did-work, but often crashes.made some short videos, but it seems very very slow and everytime I try a full run, it never succeed (infinity loop and screen freeze)

ill try to copy all the material used in prboom like you suggested

 

edit: it does work, but without sound for the portmidi (fix if possible please) problem (ill use a different sound setting like in prboom eventually)

Edited January 29, 2022 by blob1024

[Dimon12321]

6 hours ago, blob1024 said:

it does work, but without sound for the portmidi (fix if possible please) problem (ill use a different sound setting like in prboom eventually)

The music cannot be recorded when Portmidi is used. IIRC, it utilizes some external instance that oggenc2 cannot detect. So, Fluidsynth is our only choice

Edited January 29, 2022 by Dimon12321

[GoneAway]

On 1/28/2022 at 2:41 PM, Delfino Furioso said:

Hi everyone!

I've made a widescreen statusbar for Hexen and I'm facing some weird behaviour when testing it with dsda-doom.

Widescreen asset support hasn't been implemented for hexen in the software renderer. There may be some ways to make it work by chance, but it isn't complete.

Edited January 29, 2022 by kraflab

[liPillON]

oh well then.. I'll wait :)

 

keep up the good work!

[A.o.D.]

I may have uncovered an incompatibility between DSDA and PRBoom+.

 

It has to do with the speed of special 253 "Scroll Floor, Move Things".  It seems that for equivalent lengths of scrollers, DSDA moves significantly faster in certain circumstances, and can cause voodoo doll mechanisms to break.  Is this something that is of interest?  I'd probably need to make a video showing the difference, as I'm not sure I can explain it adequately.

 

[GoneAway]

1 hour ago, A.o.D. said:

I may have uncovered an incompatibility between DSDA and PRBoom+.

Sounds like you're playing on the wrong compatibility level. Slower scrolling floors in boom are broken - the voodoo doll moves slower than the floor. This is fixed in mbf21, which prboom+ does not support. If you have a specific map in mind that is broken in complevel 21 I'll be happy to add it to the list of automatic compatibility toggles so it works on mbf21 as well.

[A.o.D.]

I

12 minutes ago, kraflab said:

Sounds like you're playing on the wrong compatibility level. Slower scrolling floors in boom are broken - the voodoo doll moves slower than the floor. This is fixed in mbf21, which prboom+ does not support. If you have a specific map in mind that is broken in complevel 21 I'll be happy to add it to the list of automatic compatibility toggles so it works on mbf21 as well.

 

It's a map I'm working on in an upcoming Community Project called "Diseases and Casualties, This Year Being 1632" and the map name is "Made away themselves".

 

What's the minimum threshold for line scrollers to work correctly in PRBoom?   I'd rather fix the map to work across all ports instead of carving out a special exception.

 

Edited January 30, 2022 by A.o.D.