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

Hey! Just wondering, will you ever add negative Gamma and Level Brightness like Woof! does? If you could kindly do that, this will be my source port of choice.

I don't have any plans for a feature like that.

Speaking of Woof, are you going to add something like the "blocky" Spectres drawing? In Software rendering, I mean.

Almost a year ago I've noticed one curious bug (or intended behavior, though I think it's not and I'll explain why) in DSDA Doom in one particular place in Doomsday of UAC, which takes its roots at least from latest version of original PrBoom from 2008, and I'm really interested in the nature of this behavior, cause it's not presented in vanilla and non-PrBoom family ports.

So, first of, look at first two screenshots: first is software renderer in DSDA Doom 0.27.3, second is OpenGL, in Software fence is translucent, but in OpenGL it's normal.

Then take a look at third screenshot, it's PrBoom 2.02 from 1998, software renderer, fence is normal.

Fourth screenshot is latest Boom and there's also a normal fence.

Now, finally, fifth and sixth screenshots are Software and OpenGL renders in latest version of original PrBoom from 2008.

So, uh, why at all there's a difference? Is it, in first place, an intended behavior, though fence is normal in ports like Woof and Chocolate Doom and in vanilla? 

I encountered the same issue in DBP59 (on those cliffs' bases with trees) - software VS opengl:

On 10/29/2023 at 7:54 PM, Nikku4211 said:

melee attacks still hit even when the player is far up above the enemy

This one is fixed for the next patch fyi

On 11/10/2023 at 12:17 AM, s4f3s3x said:

Speaking of Woof, are you going to add something like the "blocky" Spectres drawing? In Software rendering, I mean.

Yes, eventually. It's not a case of just copying Woof's code unfortunately.

Hi! Now that I got a new monitor I'm trying to play at higher frame rates with g-sync (and I quite like how smooth it's now and the improved input delay). DSDA-DOOM is my sourceport of choice for classic wads but I noticed that I only get around 130-140 fps with the software renderer at 1440p. I was testing it in Ultimate Doom E1M1, of course on more complex maps like the ones in Sunlust I get a lower number. So I resorted to play in 720p to get my 165 fps which is what my monitor is rated for.

Meanwhile I tested GZDoom software renderer and I get 165 fps just fine. Is this normal? Is there any reason why dsda-doom has a poorer performance?

On 10/29/2023 at 7:54 PM, Nikku4211 said:

how do I make an enemy spawn on top of a walkable middle texture?

I've looked into this some more. It's due to how actors spawn in the vanilla engine (you see the same effect if you spawn an enemy close to a wall for instance). The "floor" isn't updated until the actor moves / crosses lines, so it uses the sector floor and ignores the 3d midtex. I would need to add an algorithm that searches for the true floor / ceiling heights when spawning, and this won't just affect 3d midtex but normal geometry as well. I won't make that kind of big change in a smaller patch, so I'll put this on the topic list for 0.28 and it can be considered a limitation of the current implementation.

6 hours ago, Azafran said:

Hi! Now that I got a new monitor I'm trying to play at higher frame rates with g-sync (and I quite like how smooth it's now and the improved input delay). DSDA-DOOM is my sourceport of choice for classic wads but I noticed that I only get around 130-140 fps with the software renderer at 1440p. I was testing it in Ultimate Doom E1M1, of course on more complex maps like the ones in Sunlust I get a lower number. So I resorted to play in 720p to get my 165 fps which is what my monitor is rated for.

Meanwhile I tested GZDoom software renderer and I get 165 fps just fine. Is this normal? Is there any reason why dsda-doom has a poorer performance?

You should try OpenGL, it's faster and basically the same as Software in DSDA Doom nowadays due to Indexed Lighting, it's with minor differences and not ideal, but still, it's pretty good in 99.9% of cases. 

1 hour ago, Vanilla+Unicorn said:

You should try OpenGL, it's faster and basically the same as Software in DSDA Doom nowadays due to Indexed Lighting, it's with minor differences and not ideal, but still, it's pretty good in 99.9% of cases. 

I already play with a hardware renderer sometimes, specially if I'm going to use freelook or some advanced mods. But for classic wads I'm using software, it doesn't look the same.

Of course using opengl I have fps to spare and I could be using a 240hz monitor easily, but I just wanted to know why dsda-doom runs worse than gzdoom (both in software) or if there is something wrong in my end and this should't happen.

Vanilla+Unicorn is right, the "new" Indexed light mode (which is the default I believe) makes OpenGL look identical to software outside of some edge cases. I suggest you give it a try.

7 hours ago, Andromeda said:

Vanilla+Unicorn is right, the "new" Indexed light mode (which is the default I believe) makes OpenGL look identical to software outside of some edge cases. I suggest you give it a try.

lol DSDA doesn't support any other light mode other than the classic Indexed light mode since 0.26.0 in Opengl i.e

all other lightmodes like glboom, sharders etc are removed since 0.26.0

What exactly is the case behind textured automap being disallowed in strict mode? Does it reveal so much of something extra it can be comparable to iddt? Or is it about something like using textures for setups?

2 hours ago, Doomy__Doom said:

What exactly is the case behind textured automap being disallowed in strict mode? Does it reveal so much of something extra it can be comparable to iddt? Or is it about something like using textures for setups?

Yeah you can reveal all sorts of extra info with a textured automap, even though most of it is edge cases. First example I can imagine is a maze where all the linedefs are hidden on the map to make it harder to find the way through, a textured automap would completely negate that unless the mapper went out of their way to make sure it didn't. I'm sure there are other situations where the textures would help the player.

Setups might also be a factor though I don't seeing this as being nearly as important.

On 11/6/2023 at 1:36 PM, plums said:

Yeah that is what's going on. It's a problem in PrB+ as well. In fact the Eviternity text file states "NOTE: GLBoom breaks skies but works other than that."

This requires stenciling which I don't think PrB+ or its derivatives have ever supported.

So something I noticed about this release was that certain wads don't seem to work properly anymore. I was attempting to load up KDiKDiZD and when I did I got the error message "1:25:Expected String Constant or Identifier." I went into the wad and got rid of all the MAPINFO lumps aside from UMAPINFO alongside other text lumps and it worked fine. I'm no programmer so I can't give suggestions on how to solve this, but I thought that it should at least be brought up so hopefully some kind of fix can be found.

EDIT: I also should point out that KDiKDiZD seemed to work properly in other versions of DSDA-Doom, which makes me think that it's this current build that caused the issue as opposed to the wad itself

@tewgytaylor @dsda-dev looks like DSDA-Doom is tripping over the SNDINFO lump, which it ignored prior to 0.27.0 (except for Hexen), but currently uses for ambient sounds.

4 minutes ago, plums said:

@tewgytaylor @dsda-dev looks like DSDA-Doom is tripping over the SNDINFO lump, which it ignored prior to 0.27.0 (except for Hexen), but currently uses for ambient sounds.

I checked this with a fresh download and yep, it was the SNDINFO lump that fixed it.

On 10/30/2023 at 5:12 PM, CacoKnight said:

And finally, why is this thread in Speed Demos and not in Source Ports?

Bringing this up again because apparently it got lost in the page turn. Makes no sense at all and only reinforces the extremely misleading idea that dsda-doom is only appealing to speedrunners.

1 hour ago, tewgytaylor said:

I checked this with a fresh download and yep, it was the SNDINFO lump that fixed it.

There have been a few cases where the parser doesn't work with all the different syntax in some SNDINFO lumps. I'll have this fixed for the next patch. Thanks for the report.

1 hour ago, ebrl said:

Bringing this up again because apparently it got lost in the page turn. Makes no sense at all and only reinforces the extremely misleading idea that dsda-doom is only appealing to speedrunners.

I've kept posting here because it's the historical home and speedrunners are the group that need to know about new releases, but you're right that it probably doesn't make sense anymore.

Are there any plans to fix the inconsistent scaling between the status bar components and the exhud components? Status bar components change their sizes based on the "status bar and menu appearance" setting while exhud components always use that setting's "not adjusted" option.

I know you can sort of fix components that use the status bar font with the exhud scale % and exhud ratio % settings. However, if you do that, then components that use regular font get messed up.

On 10/31/2023 at 1:12 AM, CacoKnight said:

And finally, why is this thread in Speed Demos and not in Source Ports?

On 11/16/2023 at 2:57 AM, ebrl said:

Bringing this up again because apparently it got lost in the page turn. Makes no sense at all and only reinforces the extremely misleading idea that dsda-doom is only appealing to speedrunners.

For what its worth, I agree. I do think it would be better if DSDA-Doom had a thread in the source ports section instead.

On 11/16/2023 at 12:12 AM, dsda-dev said:

I've kept posting here because it's the historical home and speedrunners are the group that need to know about new releases, but you're right that it probably doesn't make sense anymore. 

Yes, please. And while you are at it, it'd be a great if you added the binaries directly to your tagged releases instead of linking to somewhere on Google drive. This is standard procedure these days which all other ports follow.

On 11/18/2023 at 10:34 AM, dsda-dev said:

• Added option to hide stat labels (unectomy)

Where is this option? Sorry can't find it and thank you for the update!

When I shoot with the rocket launcher there are visible white/semi-transparent squares around the initial fire sprites, not sure what's going on there.

Maybe it was just the wad I was testing, can't even remember which one now.

8 hours ago, dsda-dev said:

 

• Added option to hide stat totals until they are reached

I can't find it, where is it?

@Vanilla+Unicorn it's a new (6th) argument to the stat_totals widget in the hud. For the default hud the line would be:

stat_totals 2 32 bottom_left 1 1 1 0 1 1

If you're using the default dsda hud you want to save this as a text file and load it with the -hud parameter, or save it as DSDAHUD.cfg and put it in your autoload folder:
 

doom full
ready_ammo_text 2 8 bottom_left
health_text 2 16 bottom_left
armor_text 52 16 bottom_left
weapon_text 2 24 bottom_left
stat_totals 2 32 bottom_left 1 1 1 0 1 1
composite_time 2 40 bottom_left
free_text 2 48 bottom_left
tracker 2 56 bottom_left
ammo_text 256 32 bottom_right
keys 241 30 bottom_right
render_stats 2 8 top_left
coordinate_display 2 8 top_left
line_display 98 8 top_left
command_display 198 48 bottom_right
event_split 10 16 top_left
level_splits 2 2 top
fps 298 0 top_right
minimap 264 8 top_right 48 48 1024
message 0 0 top_left
secret_message 0 76 none
add_offset 1 top_left

2 hours ago, plums said:

@Vanilla+Unicorn it's a new (6th) argument to the stat_totals widget in the hud. For the default hud the line would be:

 

stat_totals 2 32 bottom_left 1 1 1 0 1 1

 

If you're using the default dsda hud you want to save this as a text file and load it with the -hud parameter, or save it as DSDAHUD.cfg and put it in your autoload folder:
 

  Hide contents

 

doom full
ready_ammo_text 2 8 bottom_left
health_text 2 16 bottom_left
armor_text 52 16 bottom_left
weapon_text 2 24 bottom_left
stat_totals 2 32 bottom_left 1 1 1 0 1 1
composite_time 2 40 bottom_left
free_text 2 48 bottom_left
tracker 2 56 bottom_left
ammo_text 256 32 bottom_right
keys 241 30 bottom_right
render_stats 2 8 top_left
coordinate_display 2 8 top_left
line_display 98 8 top_left
command_display 198 48 bottom_right
event_split 10 16 top_left
level_splits 2 2 top
fps 298 0 top_right
minimap 264 8 top_right 48 48 1024
message 0 0 top_left
secret_message 0 76 none
add_offset 1 top_left

 

 

 

 

Oh, thanks, I didn't know, cause usually I don't use custom HUDs, =)

UPD:

For some reason it doesn't work for me, port doesn't even load custom HUD according to console

UPD2:

Somehow it worked, never mind, lmao

Thanks for that @plums, I started playing with those 1s and 0s and it KIND OF makes sense now :)

Is there a way to change the time color from green to gold?

BOOM!

DSDATC.lmp > "exhud_level_time 6"