dsda-doom source port [v0.24.3]

Ah, I see. I made this example dehacked by hand after seeing WhackEd4 make something similar to that so I just assumed that's how the fixed point values worked. *pulls out calculator* It works now! Thanks for the help, Xaser! :D

On 11/21/2021 at 5:09 PM, kraflab said:

You're using the latest version?

Sorry for the slow response, I was not, I was using 21.3, I messed around with 22.1 with nomo and cheating my class to change to see if it defaulted to fighter when leaving the hub and it didn't my class stayed cleric.  I can't replicate again in 22.1 so far and you probably mentioned a fix in the newest version that I didn't read.  If I encounter it again somehow I will let you know thank you for the help!

On the subject of translucent projectiles: Eternity has an option for "additive" translucency, which I think looks a lot better than the Boom one. Perhaps it could be implemented into DSDA-Doom as well?

Examples:

The latter has a much livelier look to it.

I'm not sure if that's the right place to ask, but I'm using DSDA Doom for the fist time and I have a question concerning the key bindings of the shotguns. When starting up dsda doom the normal shotgun is bound to 3 and the SSG is bound to 9, but I would like to have both shotguns bound to 3, the way it's been in the original. Am I missing something?

They will cycle if you press 3, just like normal. The direct SSG binding is just for people who like to bind every individual weapon to a key.

On 11/23/2021 at 12:46 AM, kraflab said:

• picture-in-picture (coop, fixed angle cameras, movie making)

When you say coop, do you mean like splitscreen play, or just like, multiplayer demos?

On 11/23/2021 at 12:46 AM, kraflab said:

• mapinfo, decorate, acs, udmf support

Wouldn't UDMF support break vanilla compatibility though? Everywhere I keep being told that G/ZDoom format stuff and vanilla-compatibility can't coexist (something along those lines) or that it would be a MASSIVE undertaking to have support for both.

UDMF itself isn't GZDoom-specific -- it's got a base spec that GZD extends with its own namespace and adds a bunch of gzd-specific stuffs. UDMF's base spec doesn't require any sort of GZDoom fanciness, so it can be adopted by other ports without any sort of compat shenanigans (e.g. EE).

Either way, this isn't much more difficult than supporting the Hexen map format, which dsda-doom already does :P -- kraflab knows what he's doin'.

Im trying this new port out and im not used to prboom-esque sourceports, is there a way i can get the timer shown on screen as im playing the game, and i prefer to play with a 4:3 ratio but i dont like how it stretches to fill the screen, is there a way to have a true 4:3 ratio? 

@Percy T

Timer on screen: Options -> General -> DSDA-Doom Settings -> Use Extended HUD set to Yes

or cycle through the other HUDs with F5.

4:3 Ratio: Pick a 4:3 ratio and set Aspect Ratio to Auto or 4:3, I don't think there is a way to force a non-4:3 ratio into black bar 4:3. 1400 x 1050 is the highest 4:3 ratio I could see in the options for my monitor (1080p)

Updated to the latest version, is it normal that the music slider affects both music AND sounds? As in, I can't mute the music without also removing all sounds from the game, which isn't ideal for playing Doom :p

2 hours ago, dac said:

Updated to the latest version, is it normal that the music slider affects both music AND sounds? As in, I can't mute the music without also removing all sounds from the game, which isn't ideal for playing Doom :p

You're probably using SDL as your preferred MIDI player (you can change it in Options -> General, under the "Sound & Music" tab).

The experimental build has an issue with a quirk of vanilla doom where some crushing values are uninitialized. This affects rising stairs that crush things into the ceiling in vanilla compatibility levels, so it's somewhat rare. If you are testing out 0.22, don't record on maps with such stairs until the next release.

It looks like save files from 0.22.1 are broken, although it's not intentional. EDIT: this is a side effect of support for the extended format, so consider this just another version that breaks saves.

Both the Windows stable build and experimental build have issues with looping on tracker music. I've only tested M.K.-header MOD files specifically so I don't know if this affects MODs with other headers or S3M/XM/IT, but they force a restart of the song rather than respecting the looping that the files use. Both WADs replace D_RUNNIN.

In patternbreak_bug, the intended behaviour is to jump to the fourth line of the first pattern (as indicated by the D03 in the last pattern) while in positionjump_bug, the intended behaviour is to jump to the fourth pattern (as indicated by the B03 in the last pattern).

patternbreak_bug.zip

positionjump_bug.zip

For sound / music bugs, please report them in the prboom+ thread since they should be fixed upstream first to allow all forks to benefit. And it's more likely someone will look at it sooner.

Win32 builds of DSDADoom 0.22.2:

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

Note that kraflab said : "This version is still considered experimental."

Was just about to mention about the glitching audio, but it was because I compiled it without "libsdl2-mixer-dev".

Everything seems to work just fine, but is there or will there be a support for timidity++?

So, I've checked if DSDA Doom v0.22.2 has sourceport bugs, that are in my wad. It's worth noting, that SOT is tested with GlBoom+/PrBoom+ 2.5.1.4.
 
There are two:

Some switches(linedef 210) have no sound in Gzdoom and Glboom+,PrBoom+(default compability),
(They have sound in Glboom+,PrBoom+ with default compability when "Retain quirks in Doom's sound code" is set to yes)

This bug is created, by sourceport authors. I am not going to inquire, what is the point of that. Normally switch sound should teleport with a player.
I assume the same happens with S1 Silent Teleport Switch, but that is unused in the wad(if I remember correctly). There are other wads, that use linedef 210.

That option also isn't perfect, because it causes problems with sound of generalized doors.

Maps 16 and 21 have the linedef 210 right at the beginning, if you wanna look into it.

Some flats will be messed up, if you load a save(PrBoom+, GLboom+) Maps 25, 26, 28

Basically saving does not save positions of flats, that has been moved using "Scroll Floor/Ceiling when Sector Changes Height".

Map 25 uses this effect the most, just look for linedefs 246/245.

Link: https://www.doomworld.com/forum/topic/112163-sign-of-torment-boom-compatible-32-map-megawadcompleted/

At least "Friction with -cl9" has been fixed. I'd like to wrap up everything and release Final version of the wad in December.
I am not forcing you to release new version right now, but I'd like to include information in the txt file, that versions newer than v0.22.2 can handle this wad properly.

I'll also check PrBoom+ 2.6.1um. I am aware, that you created MBF21 standard. Let's just say I can really help you when/if you'll be planing newer standard.

The sound thing isn't a bug introduced by new versions, it's a bug fixed by new versions. And those fixes are coming from boom, which is the compatibility you are targeting, so it sounds like things are working correctly. This port isn't going to change core behaviour based on your preferences, especially considering it would affect every other wad as well.

Saving flat positions: I'd suggest bringing that up in the prboom+ 2.6.1 thread, since a save file bug should be addressed upstream.

The standard group has a sufficient number of people currently involved, but thanks for the offer.

1 hour ago, kraflab said:

The sound thing isn't a bug introduced by new versions, it's a bug fixed by new versions. And those fixes are coming from boom, which is the compatibility you are targeting, so it sounds like things are working correctly. This port isn't going to change core behaviour based on your preferences, especially considering it would affect every other wad as well.

I think I was misunderstood. This switch have sound with complevel 9, but it is silent with default compability(the option is crude workaround). I've already told you everything.

I am not going to bother you again.

If you're concerned with people playing on the wrong settings, you can make the game use complevel 9 by default by adding a lump called COMPLVL with "boom" as the data (adding a simple text lump with Slade for instance).

3 hours ago, kraflab said:

If you're concerned with people playing on the wrong settings, you can make the game use complevel 9 by default by adding a lump called COMPLVL with "boom" as the data (adding a simple text lump with Slade for instance).

Ok, I will make the last one attempt. Just play Map 21, go through the door and there should be the elevator using the feature. It would take you like 5 minutes.

This is really my last attempt. I've given up. :(

23 minutes ago, Kain D. said:

 

Ok, I will make the last one attempt. Just play Map 21, go through the door and there should be the elevator using the feature. It would take you like 5 minutes.

This is really my last attempt. I've given up. :(

Adding the COMPLVL lump like Kraflab said would take you less than one minute and solve that problem though.

Updated to v0.22.3

This version is still considered experimental.

What's New:

• Added parallel sfx settings
  • Within window game tics, allow the same sound to be played limit times
• Removed -loadgame / -recordfrom
  • These were buggy and the implementation was unpleasant - this functionality will be replaced eventually like with loading within a demo.
• Fixed heretic playback desync with user pause
  • This only affected playback, not recording
• Fixed stutter when changing music with portmidi (pr+)

Download

Win32 build of dsda-doom 0.22.3:

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

On 10/31/2021 at 1:09 AM, esspressoman said:

compiling seems to be borked on arch linux

  Hide contents

/usr/bin/ld: CMakeFiles/dsda-doom.dir/MUSIC/portmidiplayer.c.o: undefined reference to symbol 'Pt_Time'
/usr/bin/ld: /usr/lib/libporttime.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [src/CMakeFiles/dsda-doom.dir/build.make:2878: dsda-doom] Error 1
make[1]: *** [CMakeFiles/Makefile2:187: src/CMakeFiles/dsda-doom.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

is the issue with portmidi?

the only thing i can think of is it being out of date,but the arch package is as new as it gets (last updated on the 27th)

id open a real issue,but those are disabled.

I'm also having this problem on Manjaro, an Arch derivative. It seems to be a Portmidi problem, because the compilation fails on various versions of DSDA-Doom, including the one I'm currently using and would like to update, 0.21.3. On the other hand, the AUR version does compile correctly using `pamac build dsda-doom`, so it's theoretically something I could fix if I knew what missing steps I needed to take.

Should be fixed by this: 

https://github.com/kraflab/dsda-doom/commit/29c967714e10b77e6e2f1dfe9372513b7a9b483e

Thanks for the try. I tried `git clone https://github.com/kraflab/dsda-doom.git` and tried to follow dsda-doom/prboom2/INSTALL, but Step 3, `make`, produced the following error output:

[100%] Building C object src/CMakeFiles/dsda-doom.dir/gl_wipe.c.o
[100%] Linking CXX executable ../dsda-doom
/usr/bin/ld: CMakeFiles/dsda-doom.dir/MUSIC/portmidiplayer.c.o: undefined reference to symbol 'Pt_Time'
/usr/bin/ld: /usr/lib/libporttime.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [src/CMakeFiles/dsda-doom.dir/build.make:2894: dsda-doom] Error 1
make[1]: *** [CMakeFiles/Makefile2:169: src/CMakeFiles/dsda-doom.dir/all] Error 2
make: *** [Makefile:136: all] Error 2

Since the AUR package works, I'll just use that for now, though it would be nice to be able to compile the program for myself. I'm sure it's some weird interaction among programs that could be ironed out in later updates. I should get in touch with the AUR package maintainer to see whether they encountered this issue and, if so, what they did to fix it.

Thanks again!