dsda-doom v0.27.5 [2023-12-03]

[bofu]

I tried posting this on the discord, but it appears to have gone unnoticed.

 

In software mode, this graphical artifact appears when the resolution is higher than 640x480 and the weapon sprite is offset horizontally during the fire animation. It's easiest to see with the SSG, and it appears to not occur if the SSG is modded to not have mismatched firing frame/muzzle flash duratuons (maybe), OpenGL is used (definitely), or resolution is lowered (most likely).

 

[PBeGood]

2 hours ago, NightFright said:

I need to see what's going on here. Maybe I have some files in autoload which are conflicting with the widescreen wad I'm using. 

 

This should work

[Duffking]

Is there any possibility that the big_ammo hud component could get the little ammo sprite next to it (bullets, shells, rockets etc) like the big_health and big_armor do? Would be the finishing touch on my current HUD setup.

Edited January 17 by Duffking

[dsda-dev]

On 1/17/2024 at 4:51 PM, Duffking said:

Is there any possibility that the big_ammo hud component could get the little ammo sprite next to it (bullets, shells, rockets etc) like the big_health and big_armor do? Would be the finishing touch on my current HUD setup.

Ya, I'll put it on the todo list.

 

On 1/16/2024 at 11:13 PM, bofu said:

I tried posting this on the discord, but it appears to have gone unnoticed.

It didn't go unnoticed, it's just an old bug inherited from prboom+ so not a new issue for discussion. I think there is a thread about it somewhere here or maybe it's back in the pr+ port thread, not sure. I don't remember the specific details to be honest.

[bofu]

5 hours ago, dsda-dev said:

Ya, I'll put it on the todo list.

 

It didn't go unnoticed, it's just an old bug inherited from prboom+ so not a new issue for discussion. I think there is a thread about it somewhere here or maybe it's back in the pr+ port thread, not sure. I don't remember the specific details to be honest.

I appreciate the response. I couldn't find any discussion of it in PrBoom+ threads and hadn't thought to test it since I've been using MBF21 lately anyway.

 

It should probably get an issue raised even if it is old, but I'll fix the SSG frames with DEH and avoid the worst of it for now, and there are a number of other workarounds at least.

[Arnier22]

Hi
Is there a way to change the controls to have it same as in zdoom?
I tried manualy, but the "strafe" I can input only one key, but I need alt+arrow
Thank you

[Arnier22]

never mind, got it

[Jakura]

While comparing past and current builds, I noticed that from v0.26.2 to v0.27 (and prevailing to v0.27.5, used in the examples below) there was a change in OpenGL's lighting that resulted in a brighter overall image, where v0.26.2 and earlier builds were closer to Software (especially in the shadows, such as in the doorway to the left).

 

Software v0.27.5:

Spoiler

 

OpenGL v0.26.2:

Spoiler

 

OpenGL v0.27.5:

Spoiler

 

The fake contrast and light fade options were introduced with v0.27, but I have them set to their defaults of "Normal" here and changing either doesn't bring the image closer to earlier versions/Software. I recall reading in a previous thread that the ongoing goal is to make Software and OpenGL modes essentially indistinguishable, with priority on the latter; so I'm curious if this was an intentional shift.

Edit: I realize it might be a little difficult to tell with the screens I chose, so here's a link to Image Comparison Slider for quick and easy comparison.

Edited January 23 by Jakura

[plums]

@Jakura interesting, I noticed a general brightness change too, but I had assumed it was due to changes in fake contrast and GL smooth lighting. You're right that this isn't the case though, and that OpenGL is always brighter in some places regardless of other settings.

[Shepardus]

On 1/21/2024 at 7:53 PM, bofu said:

I appreciate the response. I couldn't find any discussion of it in PrBoom+ threads and hadn't thought to test it since I've been using MBF21 lately anyway.

 

It should probably get an issue raised even if it is old, but I'll fix the SSG frames with DEH and avoid the worst of it for now, and there are a number of other workarounds at least.

For the record, here's the old discussion on it:

 

[Doomy__Doom]

Maybe a silly question, but is there a way to turn off stat collection temporarily, like via a command line switch? I just realised running dsda-doom through UDB spams a billion random-temp-wad-named folders in dsda_doom_data...

 

Nothing in args.c or config file stood out to me as an option to achieve that effect, but maybe (hopefully) I missed something.

[plums]

1 hour ago, Doomy__Doom said:

Maybe a silly question, but is there a way to turn off stat collection temporarily, like via a command line switch? I just realised running dsda-doom through UDB spams a billion random-temp-wad-named folders in dsda_doom_data...

 

Nothing in args.c or config file stood out to me as an option to achieve that effect, but maybe (hopefully) I missed something.

I'm not sure which option it is to turn off stat collection, but assuming there is one, you can copy dsda-doom.cfg to another file like dsda-doom-udb.cfg, and then add -config /wherever/dsda-doom/dsda-doom-udb.cfg to your testing options in UDB, and just turn it off for that config.

[JadingTsunami]

2 hours ago, Doomy__Doom said:

Maybe a silly question, but is there a way to turn off stat collection temporarily, like via a command line switch? I just realised running dsda-doom through UDB spams a billion random-temp-wad-named folders in dsda_doom_data...

 

Nothing in args.c or config file stood out to me as an option to achieve that effect, but maybe (hopefully) I missed something.

 

You could just use "-data" to send the "junk data" somewhere else. Either a /dev/null equivalent or a folder you delete every so often.

[Doomy__Doom]

9 hours ago, JadingTsunami said:

a /dev/null equivalent

Unfortunately, does not seem to function. Idk about linux, but various version of nul on Windows are ignored, presumably not passing the "exists and is a directory" test.

 

9 hours ago, JadingTsunami said:

a folder you delete every so often

I consider the spam of apriori pointless files/directories to be more of a problem than the "where" of it, tbh. I can definitely separate real stats from spam for now, but the behavior itself needs a killswitch. Surely "playtesting in UDB" is a common enough use case.

[Shepardus]

I think /dev/null doesn't work because it doesn't count as a directory. There's a console command "wad_stats.forget" to not update WAD stats, but no way to automatically execute that as far as I know. I send my data to /tmp, which on my computer is a tmpfs so it's in memory and gets cleared when I shut down my computer. Have to copy out any saves I want to keep, though, since if you use the "organize saves" feature the save location is determined by -data and not -save. I'd prefer it if it were a config key rather than a console command (configs can be assigned through the console or the -assign parameter anyway).

[JadingTsunami]

4 hours ago, Doomy__Doom said:

Unfortunately, does not seem to function. Idk about linux, but various version of nul on Windows are ignored, presumably not passing the "exists and is a directory" test.

 

4 hours ago, Shepardus said:

I think /dev/null doesn't work because it doesn't count as a directory.

 

Sorry, I realize that was a bit too abstract. I meant a conceptual "/dev/null"/"nowhere" equivalent folder somewhere, like tmpfs (as Shepardus mentioned) or a readonly folder somewhere, or something like that. But Shepardus mentions something better that makes this moot anyway:

 

4 hours ago, Shepardus said:

There's a console command "wad_stats.forget" to not update WAD stats

 

In that case, why not just add "-command wad_stats.forget" to the command line.

[Doomy__Doom]

12 minutes ago, JadingTsunami said:

In that case, why not just add "-command wad_stats.forget" to the command line.

Alas, that kills only stats.txt file, but not the directory it would've been in :)

[JadingTsunami]

4 hours ago, Doomy__Doom said:

Alas, that kills only stats.txt file, but not the directory it would've been in :)

 

Hmm, so you want something a bit different than this:

 

21 hours ago, Doomy__Doom said:

Maybe a silly question, but is there a way to turn off stat collection temporarily, like via a command line switch?

 

It's more than that, you want "output no data whatsoever during this run." I think the best option for this should be a "-data" dir to nowhere or a temporary location like before mentioned. At least, in the near term. If the developers want to consider a feature for it they can of course, but I know of nothing else available there today.

[Billy2090]

Hi,I would like to know how to install dsda doom.

I downloaded it but when I drag the wads to it it says either playpal not found or iwad not found.Have I done anything wrong?

[Shepardus]

7 hours ago, JadingTsunami said:

In that case, why not just add "-command wad_stats.forget" to the command line.

Didn't know about the -command parameter, thanks!

 

2 hours ago, Billy2090 said:

Hi,I would like to know how to install dsda doom.

I downloaded it but when I drag the wads to it it says either playpal not found or iwad not found.Have I done anything wrong?

I think dragging and dropping a WAD onto the executable would try to load it as a PWAD, so if you're doing that with an IWAD (e.g. doom2.wad) it may not work as expected. Put the IWAD in the program's folder and just launch the executable, or if you have a PWAD you want to load on top of it, drag that to the exe. If you have multiple IWADs and PWADs you want to manage, I would recommend using the command line or a launcher such as dsda-launcher or ZDL.

[Billy2090]

On 2/9/2024 at 8:32 PM, Shepardus said:

Didn't know about the -command parameter, thanks!

 

I think dragging and dropping a WAD onto the executable would try to load it as a PWAD, so if you're doing that with an IWAD (e.g. doom2.wad) it may not work as expected. Put the IWAD in the program's folder and just launch the executable, or if you have a PWAD you want to load on top of it, drag that to the exe. If you have multiple IWADs and PWADs you want to manage, I would recommend using the command line or a launcher such as dsda-launcher or ZDL.

I've got the IWads(doom,doom 2)in my dsda doom folder but it still doesn't work.Also,when I open dsda laucher,the IWads option table is blank.

[Billy2090]

7 minutes ago, Billy2090 said:

I've got the IWads(doom,doom 2)in my dsda doom folder but it still doesn't work.Also,when I open dsda laucher,the IWads option table is blank.

 

[mikeday]

Remove the “(1)” and the “ (2)” from your IWAD file names. In general you shouldn’t rename your WADs, as source ports search for them based on their official names. 

[Billy2090]

On 2/9/2024 at 8:32 PM, Shepardus said:

Didn't know about the -command parameter, thanks!

 

I think dragging and dropping a WAD onto the executable would try to load it as a PWAD, so if you're doing that with an IWAD (e.g. doom2.wad) it may not work as expected. Put the IWAD in the program's folder and just launch the executable, or if you have a PWAD you want to load on top of it, drag that to the exe. If you have multiple IWADs and PWADs you want to manage, I would recommend using the command line or a launcher such as dsda-launcher or ZDL.

 

18 minutes ago, mikeday said:

Remove the “(1)” and the “ (2)” from your IWAD file names. In general you shouldn’t rename your WADs, as source ports search for them based on their official names. 

Guys it's working now thank you very much

[Sikreci]

Hey, I haven't used DSDA-Doom for demos at all until today, when I wanted to make some demos for playtesting a community project. Anyway, the "Store Quick Key Frame" key, when pressed, seems to crash DSDA-Doom when a demo is being recorded. Not sure if "crash" is the right term exactly, but the program writes the recorded demo file and immediately exits. Storing/Restoring a quick key frame seems to work fine if no recording is active. Not sure if this is expected behavior or not, the rewind function seems to work as expected whether a demo is being recorded or not. Here's the output in the terminal:

dsda-doom v0.27.5 (https://github.com/kraflab/dsda-doom/)
dsda-doom is released under the GNU General Public license v2.0.
You are welcome to redistribute it under certain conditions.
It comes with ABSOLUTELY NO WARRANTY. See the file COPYING for details.

Playing: DOOM 2: Hell on Earth
 adding /home/sikreci/Doom/WADS/DOOM2.WAD
 adding /usr/local/share/games/doom/dsda-doom.wad
Using data file directory: /home/sikreci/.dsda-doom/dsda_doom_data/doom2

dsda_ExportKeyFrame: Failed to write key frame.
Wrote demo: /home/sikreci/Doom/test.lmp

I'm using the Linux version, built from source on Fedora 39.

[plums]

@Sikreci what key do you have as "store quick key frame"? Is it possible it's conflicting with a demo key somehow?

 

Seems unlikely to me but I don't know what else to suggest. It works for me fine on Arch Linux.

 

Post the command-line you're using to record, just in case.

[Sikreci]

You got me thinking about the command line, because I use ZDL, and it turns out it's ZDL's fault sort of. The problem is that my DSDA-Doom source port in ZDL points to /usr/local/bin/dsda-doom and it's running the game inside that directory which it has no write permissions for, so it can't write the keyframes which are actual files on the disk it turns out. My solution was to just create a symlink, so now ZDL points to /home/sikreci/Doom/DSDA/dsda-doom which is a symlink to /usr/local/bin/dsda-doom, but now it runs inside a directory it can write to and everything works fine. Cheers!

[plums]

7 hours ago, Sikreci said:

You got me thinking about the command line, because I use ZDL, and it turns out it's ZDL's fault sort of. The problem is that my DSDA-Doom source port in ZDL points to /usr/local/bin/dsda-doom and it's running the game inside that directory which it has no write permissions for, so it can't write the keyframes which are actual files on the disk it turns out.

Glad it works! I haven't used ZDL before but I would hope there's a way to change the working directory when it runs; if not, consider reporting a bug, cause that's the kind of thing that I can see affecting other people too.

[Shepardus]

I also use ZDL but haven't had a problem with it using the executable directory as the working directory because I just leave the programs in my home directory where I built them. (Also, I point ZDL to a script that I use to launch the game rather than the executable itself, but I do that to output timestamped logs to /tmp, not to change the working directory.)

 

Being able to set the working directory in ZDL would be one solution, but another would be for dsda-doom to provide the ability to set where the keyframes are written. (BTW, as you've probably figured out by now, keyframes are only written to disk if you're recording so you can continue recording from one.) -levelstat and -analysis are also written to the working directory, and I wish they took a path parameter instead.

[Xemonix]

In software mode, the screen border (which includes the status bar) only gets redrawn when a menu is active, for some reason. This makes it so that if there are any extended HUD components on top of the status bar they don't get cleared and it leads to stuff like this:

For some reason there are these very specific and kinda strange checks in d_main.c (lines 424-445)

// ...
} else {
  // CPhipps -
  // If there is a border, and either there was no border last time,
  // or the border might need refreshing, then redraw it.
  redrawborderstuff = isborder && (!isborderstate || borderwillneedredraw);
  // The border may need redrawing next time if the border surrounds the screen,
  // and there is a menu being displayed
  borderwillneedredraw = menuactive && isborder && viewactive;
  // e6y
  // I should do it because I call R_RenderPlayerView in all cases,
  // not only if viewactive is true
  borderwillneedredraw = borderwillneedredraw || automap_on;
}

if (redrawborderstuff || V_IsOpenGLMode()) {
  // ...
  R_DrawViewBorder();
}

To me, this just looks like an old optimization attempt, but I might be not getting something. In OpenGL mode it works as expected and if I set redrawborderstuff to true before the if block it works perfectly fine in software mode as well. Is it possible to just get rid of these variables and always redraw the border?