Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
dsda-dev

dsda-doom v0.26.2 UDMF [2023-06-04]

Recommended Posts

@RHhe82 and @EngineerKappa you might find the level table feature interesting.

 

Quote

#### Level Table
- Added a level table (currently at the bottom of the options submenu)
- Added tracking for completion of individual levels
  - Kills, items, and secrets
  - Time, max time, and skill 5 time for pistol starts on each map
- Added wad stats summary page with overall completion statistics
- You can warp to maps from the level table

 

Share this post


Link to post
1 hour ago, dsda-dev said:

@RHhe82 and @EngineerKappa you might find the level table feature interesting.

 

 


Well, this is a surprise! I certainly wasn’t expecting anything like this when I mentioned something like this in the crazy source port features! Gotta test it later tonight!

 

Edit: Loving the level table feature already!

Edited by RHhe82 : Tested <3 (I’m so easily pleased)

Share this post


Link to post

Out of curiosity, what kind of wads could you play with the compatibility this offers? Just so I know what to try it out with.

Share this post


Link to post
18 minutes ago, Mr Masker said:

what kind of wads could you play with the compatibility this offers?

at the moment, not a ton if you're thinking stuff that uses "zdoom features" - you'd need to cross-check what's implemented. no 3d floors, no ACS (at the moment), no decorate (not part of the map format), etc. the list of supported features is here: https://github.com/kraflab/dsda-doom/blob/master/docs/udmf.md and specials etc are listed here https://github.com/kraflab/dsda-doom/blob/master/docs/doom_in_hexen.md - it's still early days.

Share this post


Link to post

What does "zdoom 1.33" namespace mean? The ZDoom UDMF specs version 1.33? Because there are features before that that are not supported by dsda-doom. Wouldn't it make more sense to make a new namespace?

Share this post


Link to post

By the way; Not sure if this has to do with my settings -- probably does, as each time I try to be perceptive and report supposed bugs, it's always something wrong at my end :P -- but suddenly automap doesn't display map name? The associated automap setting ("level title") is set to "ON". Also, "A secret is revealed" message is no longer displayed, but the secret found sound still plays.

Share this post


Link to post
23 minutes ago, msx2plus said:

at the moment, not a ton if you're thinking stuff that uses "zdoom features" - you'd need to cross-check what's implemented. no 3d floors, no ACS (at the moment), no decorate (not part of the map format), etc. the list of supported features is here: https://github.com/kraflab/dsda-doom/blob/master/docs/udmf.md and specials etc are listed here https://github.com/kraflab/dsda-doom/blob/master/docs/doom_in_hexen.md - it's still early days.

Fair enough, good proof of concept though. Maybe people will make some cool stuff for DSDA Doom with this.

Share this post


Link to post

I suppose that if you wanted to make a vanilla or limit-removing WAD with the basic UDMF features, DSDA-Doom can run it now, right?

Share this post


Link to post
17 minutes ago, RHhe82 said:

By the way; Not sure if this has to do with my settings -- probably does, as each time I try to be perceptive and report supposed bugs, it's always something wrong at my end :P -- but suddenly automap doesn't display map name? The associated automap setting ("level title") is set to "ON". Also, "A secret is revealed" message is no longer displayed, but the secret found sound still plays.

There were some updates to the hud config stuff (basically, finalizing the migration). Most likely you need to add the new components to your custom hud, assuming you're using one.

Share this post


Link to post
29 minutes ago, boris said:

Wouldn't it make more sense to make a new namespace?

Since it's a strict subset and is still in development, I don't know if it makes sense to have a new namespace yet. The port supports the zdoom namespace in the sense that it loads it, subject to the constraints outlined in the docs. Once things are stable, and if udb support will happen (because if not, then nothing would be writing the new namespace anyway), then it probably would make sense to have a separately named namespace for convenience and so there is a "standard" that can be referenced more easily.

Share this post


Link to post

Win32 build of dsda-doom v0.26.0:

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

Mostly untested, I just got it to compile after painfully updating my build environment.

Zip file loading seems to work most of the time, However there is a problem with one of the first wad I tested (breach.zip) because it contains thumbnails in the __MACOSX directory, removing the directory fixes the problem

Share this post


Link to post
1 hour ago, dsda-dev said:

There were some updates to the hud config stuff (basically, finalizing the migration). Most likely you need to add the new components to your custom hud, assuming you're using one.

 

Oops, my bad. I haven't dabbled into custom huds (yet), but it was an issue of my DoomLauncher setup using 0.25.6 version of the dsda-doom.wad. I just knew the problem had to be at my end :P

Share this post


Link to post

Thanks for the new release! Hopefully this version will work better for me in OpenGL mode than the last one. If not, there's always software rendering to fall back on.

Share this post


Link to post

It's interesting to see that the "freeze" mode in DSDA-Doom is even more extensive than in GZDoom since it also freezes sector height updates, even though line actions are still triggered.

Share this post


Link to post

Congrats on the release!

 

I've been doing some testing and have noticed a couple things so far:

 

ENDOOM crashes when quitting DSDA Doom

  • I'm on Windows 11 (64-bit), and if you have ansi_endoom set to 1 in the config, DSDA Doom (v0.26) will always crash with a Signal 11 (0x0000) error when pressing quit. This is on a fresh config, mind you. It doesn't matter if there's an ENDOOM lump in the PWAD or not, it will always crash (I assume this means it crashes when trying to print the Vanilla Doom 2 ENDOOM). In the last major release, ENDOOM would always print correctly without a crash.

 

6 hours ago, dsda-dev said:

  - Can add renderer preference (e.g., because software rendering tricks are used)

  • Not sure how I feel about this. To be honest, I need to test what this actually does. I don't think this would be too useful for me, since players often use OpenGL for performance reasons over Software. For people with less capable computers, they may be forced to use OpenGL regardless. I'd rather try and get OpenGL as close to Software, instead of forcing people to use another render mode. I guess I'm glad it's an option, but I probably wouldn't use it in my WADs. -shrug-

 

DEHACKED Blood Color causes different coloured corpses after being crushed

  • I was meaning to bring this up in an earlier version, but I thought I'd test this version to see if it was fixed. There is a minor oversight regarding DEHACKED value Blood Color. So Blood Color does 2 things. When you shoot an enemy, it changes the color of the blood splatter that comes off the enemy (example: red -> blue). What it also does is when an enemy corpse is crushed, the Doom engine changes the corpse to a smaller pool of blood. Blood Color also changes this blood pool to match the spatter color.

    I did notice that the way this version of DSDA Doom does Blood Color is a bit different. Previous version would take some red values from the palette and translate them to match the Blood Color value. However it seems like this new version does it differently and recolours the entire sprite.

    dsda-blood-color.jpg

    How do I know this? Well, because the Blood Color effect on the pool of blood is not reverted if the enemy is resurrected by an Archvile. This leads to the resurrected monster having the colour of Blood Color value. In the old versions of DSDA Doom, this was less noticeable because it only affected the dark red values that were the same values of the pool of blood corpse. This meant that it was only really noticeable with the Cacodemon since it shared some of the same red palette values as the recoloured pool of blood. However because of how the new version of DSDA Doom colours the pool of blood, it's alot more noticeable now. I'm sure that other monsters will become fully recoloured and notable now.

    Anyway it probably seems like the best way to fix this would be to put a check when a monster crushed corpse is resurrected to return to its normal palette.

 

OpenGL Indexed Render Mode is getting better, but still isn't perfect.

  • I will say that I did test out the new DSDA Doom with some Vanilla style maps, and it does seem to render stuff a bit better than the last version. Specifically on of my pet peeves was how it would always render floors above ceilings and the walls would always be visible above the sky, whereas in Software the sky would obscure the wall. You can see from the screenshots below, the improvement:

    Software Renderer:
    dsda-software-hrs-example-1.jpg dsda-software-hrs-example-2.jpg

    OpenGL Indexed DSDA v0.25.6:
    dsda-indexed-hrs-example-1.jpg

    OpenGL Indexed DSDA v0.26:
    dsda-indexed-hrs-example-2.jpg

    As you can see it's not perfect. It seems that it still doesn't like when a floor is above the ceiling when that ceiling isn't the sky.

    As for another thing on my Indexed wishlist, it'd be support for midtex bleeds:
    dsda-midtex-bleed.jpg

 

Overall it is great to see the port get improvements. Glad to see DSDA Doom is still getting updates!

Share this post


Link to post

So compiling it on linux now requires libzip, but for some reason it also requires having /usr/bin/fluidsynth and /usr/bin/zipcmp installed at build time, and not just the development libraries for libzip and fluidsynth.

 

Even stranger is that you don't need /usr/bin/zipcmp nor /usr/bin/fluidsynth installed to run dsda-doom.

Share this post


Link to post
Quote

For people with less capable computers, they may be forced to use OpenGL regardless. I'd rather try and get OpenGL as close to Software, instead of forcing people to use another render mode. I guess I'm glad it's an option, but I probably wouldn't use it in my WADs. -shrug- 

The point of this feature is for exceptions where the renderer is critical. For instance, if you play Major Arlene's drudge map with the software renderer it will be completely messed up because it uses things only supported in opengl currently. It shows a warning message in the top left in that case so the player knows. Another case would be vanilla maps heavily reliant on software visual tricks. For most cases this feature isn't needed, but that's up to the author's discretion.

Share this post


Link to post
1 hour ago, Arsinikk said:

This leads to the resurrected monster having the colour of Blood Color value.

Wow that's a funny bug 😄

I'll have it fixed for the next patch

Share this post


Link to post

Should you be able to see the .exe screen before the game starts? Or is my laptop just old and slow 😅😅

Share this post


Link to post

I haven't been getting any stutters on the OpenGL renderer, which is great! I do have a few HUD wishlist items:

  • There should be a way to remove the "WPN" label for the weapon_text component like what you can do for ammo_text and composite_time
  • big_ammo is always red; it isn't yellow, green, or blue based on the amount of ammo you have
  • There's no way to change the color of big_armor_text, big_health_text, etc. with the DSDATC lump like you can with health_text

Also, if you're on the full HUD, is it possible to have the black BG automap along with no status bar?

Share this post


Link to post

I'm SO stoked to see a new release out. I've totally dropped the ball on testing/finding stuff but I'll be doing all my Dooming with this new build and will of course share if I find any issues. Happy as hell about all the progress!

Share this post


Link to post

Why are comments not marked as supported in the docs? All that's needed to "support" comments is to silently ignore them...

Share this post


Link to post
Just now, boris said:

What does "zdoom 1.33" namespace mean? The ZDoom UDMF specs version 1.33? Because there are features before that that are not supported by dsda-doom. Wouldn't it make more sense to make a new namespace?

 

I was also wondering about the ZDoom 1.33 namespace. What does that mean? There were ZDoom version 1.23 builds and then the version number jumped to 2.0. There was no ZDoom 1.33 (unless this number is something else that I don't get).

Share this post


Link to post
4 hours ago, Gez said:

Why are comments not marked as supported in the docs? All that's needed to "support" comments is to silently ignore them...

They're not supported in the sense that they aren't parsed and don't do anything. I'm planning on adding an option to display the comment in the port, and then I will mark them supported (something like a console command to access the comment of the current sector for instance).

Share this post


Link to post
27 minutes ago, ReaperAA said:

 

I was also wondering about the ZDoom 1.33 namespace. What does that mean? There were ZDoom version 1.23 builds and then the version number jumped to 2.0. There was no ZDoom 1.33 (unless this number is something else that I don't get).

As boris mentioned in his comment, this is the namespace version.

Share this post


Link to post

I'm not sure if I should be asking this here, if it was previously discussed please let me know. I was recording demo on v0.25.6 (not shifted to the latest yet) and found this. How many attempts I took I see that these many demo files created.

image.png.3547f16b35817b35a93655209b79bba7.png

 

I want to share this too

image.png.27296b6ec897220ace9e7922c3902268.png

 

So I want to know if there is any way to prevent this. Like how I record demo on PrBoom, it overrides the existing demo file.

Share this post


Link to post
Guest
This topic is now closed to further replies.
×