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

16 hours ago, dsda-dev said:

Updated to v0.27.4 (same link in first post)

• Added background fps limit menu option

What does  ` background fps limit menu ` mean ?

Also, what does gl smooth light fade option do ?

(sorry for asking this question too lately, i haven't looked at the feature until few mins ago)

@Vanilla+Unicorn @CacoKnight the full DSDA HUD specs are here: https://github.com/kraflab/dsda-doom/blob/master/docs/hud.md

The 1s and 0s after a component just control whether some options are on or off for that component. Some options take multiple numbers, like colours for stuff, as you figured out.

My eyes kind of glazed over when I first started to play with the options but if you just take the default HUD and adjust things one component at a time it's not so bad.

There are some configs posted by me and other people here and here if you want to try out new ones.

@Classic SSG Enjoyer

Background limit FPS: when you're looking at another program etc., DSDA Doom runs with a lower FPS so it doesn't use as much CPU.

GL smooth light fade: when it's off, the GL renderer mimics the light banding that you get from software mode. When it's on, the fading is smoother. The effect is a bit subtle but you should be able to notice it a bit in darker areas especially. (Also see the bottom of page 5 in options, "Fullscreen menu background", set it to No so you don't get the options menu background and you can see changes in video options more immediately.)

3 minutes ago, plums said:

@Vanilla+Unicorn @CacoKnight the full DSDA HUD specs are here: https://github.com/kraflab/dsda-doom/blob/master/docs/hud.md

 

The 1s and 0s after a component just control whether some options are on or off for that component. Some options take multiple numbers, like colours for stuff, as you figured out.

 

My eyes kind of glazed over when I first started to play with the options but if you just take the default HUD and adjust things one component at a time it's not so bad.

 

There are some configs posted by me and other people here and here if you want to try out new ones.

 

@Classic SSG Enjoyer

Background limit FPS: when you're looking at another program etc., DSDA Doom runs with a lower FPS so it doesn't use as much CPU.

GL smooth light fade: when it's off, the GL renderer mimics the light banding that you get from software mode. When it's on, the fading is smoother. The effect is a bit subtle but you should be able to notice it a bit in darker areas especially. (Also see the bottom of page 5 in options, "Fullscreen menu background", set it to No so you don't get the options menu background and you can see changes in video options more immediately.)

Thanks Plums 👍. Understood.

19 minutes ago, plums said:

@Vanilla+Unicorn @CacoKnight the full DSDA HUD specs are here: https://github.com/kraflab/dsda-doom/blob/master/docs/hud.md

 

The 1s and 0s after a component just control whether some options are on or off for that component. Some options take multiple numbers, like colours for stuff, as you figured out.

 

My eyes kind of glazed over when I first started to play with the options but if you just take the default HUD and adjust things one component at a time it's not so bad.

 

There are some configs posted by me and other people here and here if you want to try out new ones.

 

@Classic SSG Enjoyer

Background limit FPS: when you're looking at another program etc., DSDA Doom runs with a lower FPS so it doesn't use as much CPU.

GL smooth light fade: when it's off, the GL renderer mimics the light banding that you get from software mode. When it's on, the fading is smoother. The effect is a bit subtle but you should be able to notice it a bit in darker areas especially. (Also see the bottom of page 5 in options, "Fullscreen menu background", set it to No so you don't get the options menu background and you can see changes in video options more immediately.)

also, gl smooth light fade is set to 'Normal' its off, right ?

Just now, Classic SSG Enjoyer said:

also, gl smooth light fade is set to 'Normal' its off, right ?

Yeah, off is the traditional Doom look.

1 minute ago, plums said:

Yeah, off is the traditional Doom look.

Thanks 👍

I was recently working on a map that used mikoportal vertical scrolling walls and was surprised to find that they no longer work in the OpenGL Indexed mode.

What's interesting is that they used to work in the Indexed OpenGL Renderer. It seems that it was DSDA Doom v0.26.0 that broke the mikoportal rendering, as in v0.25.6 they rendered correctly.

Kinda bringing this up cuz I tend to use mikoportals in my maps and they used to work fine in Indexed Renderer.

Win32 build of dsda-doom 0.27.4

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

Is there any way to unbind F1 as help? I'd like to use it for artifacts in Heretic/Hexen but I can't seem to override it bringing up the help screen.

I've noticed one bug with OPL, apparently, sometimes volume of audio reduces and samples disappears.

I don't know how to reproduce it, but it happens very often when you're playing.

It fixes with changing MIDI player or increasing / decreasing volume.

It's more strangier, because I use latest version (0.27.4) in which it was fixed already.

Can it be due to an old configuration file?

Hey guys, how the hell did he turn on "true color renderer" in DSDA? Can't find that option to save my life, I like 8-bit more but I'd still like to know. Thanks.

edit:

I think I found out why, tried some older versions of DSDA and 0.24.3 loads true color instead of 8-bit palette.

6 hours ago, CacoKnight said:

Hey guys, how the hell did he turn on "true color renderer" in DSDA?

It's been deliberately removed.

On 11/9/2023 at 11:45 PM, Vanilla+Unicorn said:

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?

 

[lots of images snipped]

The so-called sky hack, which omits an upper texture between two sky ceilings, is implemented by pretending the ceiling height of the front sector is actually the height of its back sector when rendering the seg. It is as if the front sector no longer has a ceiling; it has been merged with the ceiling of the back sector.

// hack to allow height changes in outdoor areas
if (frontsector->ceilingpic == skyflatnum
    && backsector->ceilingpic == skyflatnum)
{
    worldtop = worldhigh;
}

In the space windows in UAC_DEAD.WAD -- the pictured observation deck (sector 360), and another at the start of the level, behind a fence (sector 65) -- the sky ceiling of the back sector is below the floor height of the ledge in front. Thus the adjustment of the ceiling height of the ledge sector takes it to below the level of its own floor. This seems to make the sky over the ledge bleed out into the floor under it.

_{A screenshot of a small test map. What it should look like -- what it looks like in Chocolate Doom -- is in the inset.}

The front sector ceiling being replaced and subsumed by the back sector ceiling, which now extends out over the front sector, is clearer to see if we are able to raise and lower the sky wall (by, say, making it into a door).

The fix seems to be to never pretend a sky ceiling has a height below its own floor. Do not blithely lie that the ceiling height of the front sector is always the same as the ceiling height of the back sector on a sky hack wall; limit your fibbing to the higher of the two.

--- a/src/r_segs.c
+++ b/src/r_segs.c
@@ -631,7 +631,15 @@ void R_StoreWallRange(const int start, const int stop)
       // hack to allow height changes in outdoor areas
       if (frontsector->ceilingpatch == skyflat
           && backsector->ceilingpatch == skyflat)
-        worldtop = worldhigh;
+      { 
+        // Pretend the front sector's sky ceiling is at the height of the back,
+        // but do not lower it below its own floor height, else sky may be
+        // seen through the floor in front of a sky wall (cf. uac_dead sec. 360)
+        if (worldhigh < worldbottom) 
+          worldtop = worldbottom;
+        else
+          worldtop = worldhigh;
+      }

       markfloor = worldlow != worldbottom
         || backsector->floorpatch != frontsector->floorpatch

It generally seems to improve rendering around sky hack walls, at least in a few places I have tested. I am sufficiently confident to not immediately revert the patch in my own engine. But I would not be surprised at all to find there is at least one map out there that depends on this bug not being fixed. More testing is needed.

As for Chocolate Doom I am not sure why it draws the ledge plane, because the sky plane's lower extent covers it. I think it depends on the order of the visplane array, and worse, there is overdraw happening, which proves this is a bug, since in general Doom goes to such lengths to avoid overdraw. But the sky plane is painted down to the lower texture in front of the ledge, then the ledge plane is painted over the top of the sky. If I swap the planes before they are rendered, the ledge plane disappears, as now the sky is rendered second. There is perhaps another plane clipping bug in vanilla that PrBoom or one of its ancestors (LxDoom?) fixed, exposing the sky hack ceiling below floor bug described above. This needs further investigation.

I recently tried this port and really liked it, thanks for the work done! Therefore, I would like to point out several shortcomings found:
1. There is no "true" 16:10 aspect ratio like in vanilla, this is what it looks like now:

And here's what it should look like:

At the moment the picture in the game is a little "squished" in this ratio.
2. Please add to the graphics settings menu in the game the ability to change the "boom_translucent_sprites" parameter to give the game a more original look.
3. The "allow jumping" option lacks the "default" value, so that it is possible to jump only when it is intended by the author.

2 hours ago, r@nd0m said:

I recently tried this port and really liked it, thanks for the work done! Therefore, I would like to point out several shortcomings found:
1. There is no "true" 16:10 aspect ratio like in vanilla, this is what it looks like now:

Doom was never meant to be 16:10. 320x200 has always been presented in 4:3 aspect ratio and that is what nearly all ports adapt the display for. The upper image is how it is supposed to look.

3 hours ago, Professor Hastig said:

 

Doom was never meant to be 16:10. 320x200 has always been presented in 4:3 aspect ratio and that is what nearly all ports adapt the display for. The upper image is how it is supposed to look.

 

 

I knew that an adept of 4:3 would appear, to whom I would first advise to look at the Doomguy face and the fireballs of the imps before stating anything.

7 minutes ago, r@nd0m said:

I knew that an adept of 4:3 would appear, to whom I would first advise to look at the Doomguy face and the fireballs of the imps before stating anything.

It's an old argument: https://doomwiki.org/wiki/Aspect_ratio

6 hours ago, r@nd0m said:

allow jumpin

The default is already "if intended by the author". This setting is an override if you want to allow it all the time. I can update the text. Boom sprite stuff can be changed in the config file or via the in game console. I'll be giving the whole menu system a look for 0.28.

Maybe I'm too new to Doom to understand what people look for in the game and how they like to play but I have to ask this, why there is no way to disable infinitely tall actors in DSDA?

22 minutes ago, CacoKnight said:

Maybe I'm too new to Doom to understand what people look for in the game and how they like to play but I have to ask this, why there is no way to disable infinitely tall actors in DSDA?

Only when the "Passover" flag is set in MAPINFO, or you're playing a game that natively supports non-infinite-height actors like Heretic or Hexen.

Just now, JadingTsunami said:

Only when the "Passover" flag is set in MAPINFO, or you're playing a game that natively supports non-infinite-height actors like Heretic or Hexen.

Oh I see, now, is there a way to make that permanent with a lump setting or ...?

16 minutes ago, CacoKnight said:

Oh I see, now, is there a way to make that permanent with a lump setting or ...?

Not in dsda-doom.

2 hours ago, rfomin said:

It's an old argument: https://doomwiki.org/wiki/Aspect_ratio

OK, but what about proportionality? How can I get a proportional image without the "squashing" effect? I would like to be able to change the base aspect ratio because I don't like looking at oval models.

23 minutes ago, r@nd0m said:

OK, but what about proportionality? How can I get a proportional image without the "squashing" effect? I would like to be able to change the base aspect ratio because I don't like looking at oval models.

What resolution are you running dsda-doom at? If you set a resolution that's a 16:9 ratio like 1920x1080, and then force a 16:10 aspect ratio, you should get the effect that you want.

9 hours ago, plums said:

What resolution are you running dsda-doom at? If you set a resolution that's a 16:9 ratio like 1920x1080, and then force a 16:10 aspect ratio, you should get the effect that you want.

The problem is that I did exactly that and ended up with the disproportionate image shown in the first screenshot.

13 minutes ago, r@nd0m said:

The problem is that I did exactly that and ended up with the disproportionate image shown in the first screenshot.

My mistake, I was just eyeballing things between your screenshots and dsda.

Using a resolution of 1680x1050 and setting the aspect ratio to 4:3 gives the same proportions as your second screenshot, though you don't get quite as wide of an image.

On 11/19/2023 at 5:16 PM, Arsinikk said:

I was recently working on a map that used mikoportal vertical scrolling walls and was surprised to find that they no longer work in the OpenGL Indexed mode.

Can you make a minimal wad demonstrating the problem?

1 hour ago, dsda-dev said:

Can you make a minimal wad demonstrating the problem?

Yes sir

Rabbit.wad

Software renders the scrolling walls normal (sort of - prboom and dsda software renderers render sprites through the scrolling walls, when vanilla does not... Check out the map in Chocolate to see how it deals with the sprites vs DSDA software. Strangely enough Woof ports render this correctly)

PrBoom OpenGL and the old OpenGL Indexed mode from v0.25.6 rendered the scrolling walls correctly, while any DSDA Doom version renders them strangely in OpenGL.

Updated to v0.27.5 (same link in first post)

• DSDAHUD lumps are "merged" now so only redefined huds are changed

• Fixed umapinfo bunny scroller crash

• Fixed volume issue on song restart in OPL (rfomin)

Getting this one out since the umapinfo crash affects a few projects.