dsda-doom source port [v0.24.3]

[Gregor]

15 minutes ago, kraflab said:

Did you switch renderers? Those options only work in opengl mode.

Ahhhhhh..... Thank you, i didn't know that.

[Ramon_Demestre]

Win32 build of dsda-doom v0.22.1

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

[BionicLuke]

Would it be possible to implement an option to either disable or set another translucency level only for sprites (as in enemy projectiles, torches, etc.) as opposed to wall textures? I really dislike translucent sprites but some mapsets do use translucent textures for secrets and whatnot that I would still like to see translucent.

 

I think the current version of prboom-plus already has the option to disable sprite translucency in its settings ("no predefined translucency for some things"?) that could maybe be used as a reference.

 

Thank you regardless for the outstanding work you've done with both this port and MBF21, I'm no speedrunner but this quickly became my favourite port to use anyways.

[Dweller Dark]

I recently went back to DSDA-Doom due to it's Heretic/Hexen support, and also because I eliminate the need to use multiple sourceports with it. But I was wondering, will/can Strife be supported down the line? 

[Maribo]

35 minutes ago, BionicLuke said:

Would it be possible to implement an option to either disable or set another translucency level only for sprites (as in enemy projectiles, torches, etc.) as opposed to wall textures? I really dislike translucent sprites but some mapsets do use translucent textures for secrets and whatnot that I would still like to see translucent.

 

It's not implemented in DSDA-Doom itself, but for casual play, you can load notransl.deh alongside any other files for the desired effect.

[El Juancho]

36 minutes ago, Eddie 2077 said:

I recently went back to DSDA-Doom due to it's Heretic/Hexen support, and also because I eliminate the need to use multiple sourceports with it. But I was wondering, will/can Strife be supported down the line? 

[Dweller Dark]

8 minutes ago, El juancho said:

 

I completely forgot I read that until now, but thank you for answering my question though!

[OpenRift]

On 11/18/2021 at 1:37 PM, OpenRift said:

One thing I think it really does need though is the ability to also do vanilla-style quicksaving/quickloading, where it saves to an entry in the Saves menu instead of doing the Quake-like thing where it only loads if you press F9. That's the only significant drawback I see here.

Okay, looking further at the patch notes, I see this was newly added. Is there a way to revert to the old quicksave system? I think it would be nice to have both options available.

[BionicLuke]

1 hour ago, Maribo said:

 

It's not implemented in DSDA-Doom itself, but for casual play, you can load notransl.deh alongside any other files for the desired effect.

Thanks a lot for this!

[GoneAway]

4 hours ago, OpenRift said:

Okay, looking further at the patch notes, I see this was newly added. Is there a way to revert to the old quicksave system? I think it would be nice to have both options available.

I don't see any point to regress there. You can easily make a manual save when you want a copy of the quicksave in a specific slot.

[tengv]

I don't want to jinx it but the FPS Limit option seems to have fixed any issues with input lag I had (using a g-sync monitor).

Setting FPS Limit to 141 (I use a 144hz monitor), with vsync off, framerate uncapped, in OPENGL mode, and using 1440p resolution I now no longer experience any input lag. It feels so good...

[OpenRift]

1 hour ago, kraflab said:

I don't see any point to regress there. You can easily make a manual save when you want a copy of the quicksave in a specific slot.

Well it seems a bit silly to not have quicksaves go to a save slot when there are literally 112 save slots available to use. Not to mention that quicksave confirmation dialogue has saved me (and I'm sure plenty of others) more times than I'm willing to admit from saving my game when there's a rocket 2 inches from my face. On a practical level, the old method was better. So why not allow people to choose between the two? People have F6+Y/F9+Y ingrained in their muscle memory anyway.

[dew]

9 minutes ago, OpenRift said:

People have F6+Y/F9+Y ingrained in their muscle memory anyway.

I don't.

[OpenRift]

18 minutes ago, dew said:

I don't.

Then you know I'm not talking about you

[dew]

https://xkcd.com/1172/

[Shepardus]

Either way, F2+Enter+Enter/F3+Enter is the superior save/load flow.

[GoneAway]

55 minutes ago, OpenRift said:

On a practical level, the old method was better

Not really. It's different from how every game on earth implements quicksaves for one thing. You can open the save menu with a key and hit enter twice if you want. That's one extra key press but still 2 keys involved, so it should satisfy you quite well, and you can ingrain it into your muscle memory in no time. Adding an option to the already swelling menus or config file and adding code to handle different methods of quicksaving when the option is already effectively there is a waste of effort and adds pointless complexity to the code.

[GoneAway]

2 hours ago, tengv said:

I don't want to jinx it but the FPS Limit option seems to have fixed any issues with input lag I had (using a g-sync monitor).

That's great to hear :^)

[Eric Claus]

This is for Hexen support and not 100% sure if it's fully source port related or has already been reported.  On Shadows of Chronos I noticed that when I went through a portal in the hub level into another map my class was not maintained, playing as Mage and ended up becoming fighter but my inventory and such was otherwise the same.  I am wondering if the class state changed between shifting maps from a hub or what happened, wasn't in issue going from intro level to the hub level initially.  I tested this on Chocolate Hexen and had not seen any issue.

[GoneAway]

You're using the latest version?

[maxmanium]

Mundane question -- what will qualify dsda-doom for a 1.0 release? :)

[Gregor]

5 hours ago, maxmanium said:

Mundane question -- what will qualify dsda-doom for a 1.0 release? :)

Final release?

[BlueThunder]

6 hours ago, maxmanium said:

Mundane question -- what will qualify dsda-doom for a 1.0 release? :)

Good question,  What constitutes it changing version numbers like that, For Example Woof went from 7 to 8 on its recent release.

Edited November 22, 2021 by BlueThunder

[GoneAway]

Here's a list of big things I have in my sights. I may change my mind over time, but I won't call it 1.0 until all the core features are implemented, and right now I still consider the port incomplete.

 

Formats

• finished doom-in-hexen support
• heretic-in-hexen and hexen-in-hexen support
• mapinfo, decorate, acs, udmf support

Demos

• basic tas building
• accurate rewind support for heretic & hexen
• ability to record nearly everything
• demo clipping

Graphics

• decoupled game world resolution and window resolution
• picture-in-picture (coop, fixed angle cameras, movie making)
• new menus / font / palette system

Miscellaneous

• improved controller support
• dynamic music replacement

[L0l1nd3r]

When slowing down game speed the framerate goes with it, but GPU (GeForce Experience) still reports 144fps. In all previous versions, (before 0.22) this was buttery smooth with perfect interpolation for actor movement and framerate. Now it's a slideshow.

[GoneAway]

28 minutes ago, L0l1nd3r said:

When slowing down game speed the framerate goes with it, but GPU (GeForce Experience) still reports 144fps. In all previous versions, (before 0.22) this was buttery smooth with perfect interpolation for actor movement and framerate. Now it's a slideshow.

This is a side effect of the refactoring to fix the stuttering problem, I'll fix it for the next release - for now I guess stick with the previous version for tasing.

[Xyzzу]

There seems to be no way to open an issue on Github so I'll just post here :P

 

Are the arguments for the MBF21 weapon codepointers broken or am I missing something here?

Example DEH

 

Here, the shotgun has been modified to have a spread of 20 degrees and a different damage roll, but in-game it has zero spread and has its default damage/dice. The fist has also been changed but doesn't work at all. If I were to remove Args5 from its attack frame, then the player can punch things but still do no damage.

[Xaser]

I'm on my phone so I can't look at the DEH itself yet, but my guess with the shotgun spread is that you're setting the args value directly to 20 -- the value is interpreted as a fixed-point number, so you'll need to multiply it by 65536 in order to get an actual 20-degree spread.

 

How are you editing the DEH? These sorts of ugly wrinkles are supposed to be smoothed over by whatever tool you're using. Try "20.0" instead of "20" in the tool and see if that does it.

 

[EDIT] The 5th arg ("range") of A_WeaponMeleeAttack is also a fixed-point number, so it's probably the same thing fhere.

Edited November 24, 2021 by Xaser

[Xyzzу]

It already is 20.0, in fact I made sure every arg with a fixed point number had ".0" at the end in the DEH posted, same result unfortunately.

 

I made this DEH partially as an excerpt from a WAD I'm working on, so maybe I'm doing something wrong with the MBF21 codepointers. There seems to be no actual WADs that modified the weapons yet so I can see how it's done, heh.

Edited November 24, 2021 by Xyzzy01

[Xaser]

At home now, so I'm able to take a look at the patch itself, and my suspicions were correct. Unfortunately, you can't enter "20.0" directly in the actual dehacked patch itself -- the DEH format stores decimal values as super-ugly fixed-point numbers (i.e. https://doomwiki.org/wiki/Fixed_point ), and 20.0 in fixed-point is written as 1310720 (i.e. 20 x 65536). The "20.0" thing is a suggested convention for tools to do this number conversion automagically -- i.e. if you type a .0 after the number, it knows to convert it to an ugly fixed-point number when reading/writing the patch. DECOHack does this; dunno what WhackEd4 does just yet 'cause I haven't been keeping up with it. Either way, if you put "20.0" in the actual patch itself, the game's not gonna parse the value correctly.

 

Did you edit this by hand, or was this patch produced by a WhackEd4 pre-release build of some sort? If it's the latter, it's something worth bugreporting to WhackEd4. If you're hand-editing it though, there's no easy shortcut here aside from whipping out a calculator app. The DEH format (and, by extension, MBF21) are just not human-friendly, despite what the Boom team tried to do ages ago. :P