dsda-doom source port [v0.24.3]

28 minutes ago, Never_Again said:

You don't need all these cmd-line arguments when playing back a demo, only when recording.

Oh, now I see. :^)

28 minutes ago, Never_Again said:

dsda-doom -playdemo C:/Users/lenovo/Desktop/test.lmp -auto

Yeah, this one works. Thanks a lot.

I finally realized what the problem was. It has something to do with command "-warp X". 0.22.4 can only play demo when the X is 1, but this won't happen with 0.21.3.

With demo playback -warp is used to go directly to a specific map point in a multi-level demo. If you want to go to a specific time point within a single-level demo use -skipsec, e.g. -skipsec 2:54 or -skipsec 174. You don't need either to simply play back a demo from start to end, the -auto switch takes care of everything.

On v0.22.4, it crashes if I use "-warp 27", if not, it plays fine.

But on v0.21.3 it plays either way

Error from v0.22.4:
 

Edit: oops nevermind, didnt see the last replies

5 hours ago, Never_Again said:

With demo playback -warp is used to go directly to a specific map point in a multi-level demo. If you want to go to a specific time point within a single-level demo use -skipsec, e.g. -skipsec 2:54 or -skipsec 174. You don't need either to simply play back a demo from start to end, the -auto switch takes care of everything.

Is there a way to detect if a demo is multi-level or not, just by reading the .lmp data?

No, the demo file says where it starts and all the inputs that were made, but you can't tell when an intermission or exit happens.

So, is crashing when trying to -warp on a single level demo the expected behaviour? 

Ive done some testing, and the playback warp system seems inconsistent.

Take, for example,  a doom2 ep3 run.

If you want to playback map21:

• -warp 1 - works
• -warp 21 - does not work

if you want to playback map22:

• -warp 2 - does not work

• -warp 22 - works

Should this be addressed or is it the expected behaviour?

3 hours ago, kraflab said:

No, the demo file says where it starts and all the inputs that were made, but you can't tell when an intermission or exit happens.

True, a human can't, but he could write a program/script that would run prb+ (or DSDA-Doom) with -timedemo and -levelstat and parse the resulting levelstat.txt. A simple -timedemo and parsing the console output for multiple FINISHED: <mapname> lines is another way to do it.

3 hours ago, PBeGood4 said:

So, is crashing when trying to -warp on a single level demo the expected behaviour?

Since using -warp with a single-level demo falls into the "user error" category I suppose the answer is "yes".

3 hours ago, PBeGood4 said:

Ive done some testing, and the playback warp system seems inconsistent.

It's even more complicated than your examples suggest. With D1 demos -warp works as expected, but without crashing on single-level demos. So indeed, there's a bug there that's probably 10 years old and it should be addressed upstream, in prboom-plus.

Testing lasting binary linked in the thread (page 32)

Enabling Launcher prevents game from loading.

Something that for me is one of the major reasons of using Prboom in the first place, the convenient launcher for mods. I don't think command-lines are anywhere near acceptable for anyone as far as 2021. Even Windows 3.11 programs had GUI interface launchers. It's becoming a bit embarassing. And no, nobody should use a 3rd party executable to do the same thing as the main executable could do the entire time. (gzdoom people, don't even start typing, I will ignore you)

Quote

M_LookupDefault:
launcher_history10621763360653321 not found

Also, mouse movement. It seems like DSDA is plagued by the HORRID mouse movement that (for whatever reason) SDL 2.0 brings to the table. (Zandronum users always complaining about this in their forum, and also being ignored...)

I just went into my prboom 2.5.1.4 directory to check, and yes, that Prboom (last functional "old" version before people start messing with it) still uses SDL 1,

Mouse movement behaves as normal in that one. Instant mouse, raw_input, as it should be (even after suffering layers of software interference being that I use Prboom inside of Wine on Linux, X screen server controls the mouse to some extent even if you disable acceleration)

No issues there, in SDL 1.

I don't have Chocolate Doom installed here in order to check if that one uses SLD 1 or 2 (I think it updated to SDL 2 at some point) I only know that mouse movement is also HORRID in that port. (it was so horrid I didn't even kept the files in the folder, damn, that was surprising even to me)

I don't think you will see masses of people converting to your port unless you provide functioning mouse movement.

I really wish that we would FINALLY have an alternative for playing Heretic and Hexen games, thus not depending on gzdoom anymore. This mouse movement won't cut it.

Even my Doom Legacy 1.40 (2004) executable that I have here has decent mouse movement, among all the other problems it has to run in modern systems, at least that's not a problem there. (OK I think the dead horse is properly beaten at this point)

On the positive side, IDDQD for resurrecting is insanely useful.

:\

Also, don't waste precious amounts of your free time and energy answering to paragraphs by the "gzdoom guy" trying to convince you to do things the way he does. You are absolutely right when you say an exclusive channel for bug reporting is not needed and an additional layer of login/accounts most people won't bother with.

That guy always does that, he sucks people in with the vast paragraphs of whatever points he's trying to make, and in the other end of it you always feel like you have wasted your time with something that didn't achieve anything of real value. It's about time someone starts to shame that kind of behavior, because people like that never stopped these things until you shame them. It's enough "diplomacy", for diplomacy to work it has to come from two ends, not just from you.

Are you ok?

8 hours ago, DwarfCleric said:

-snip-

...wut?

@DwarfCleric , you could really learn to be nicer. Anyway...

10 hours ago, DwarfCleric said:

Enabling Launcher prevents game from loading.

Seems like a bug/issue that seems to be happening on only your end. I use the launcher myself and it works fine. I would recommend creating a new config and see if it works. Alternatively, if that doesn't work, try this .cfg file: dsda-doom.zip

10 hours ago, DwarfCleric said:

Also, mouse movement. It seems like DSDA is plagued by the HORRID mouse movement that (for whatever reason) SDL 2.0 brings to the table. (Zandronum users always complaining about this in their forum, and also being ignored...)

You are likely referring to the mouse lag that seems to sometimes exist in certain SDL2 ports. I am sure kraflab fixed the mouse though. But if its still not working for you, I would recommend turning OFF Vsync in options (that seems to fix it for pretty much every SDL2 port I have come across).

I also recommend turning ON "carry fractional tics" and "no vertical mouselook" in mouse options if you haven't done so already.

On 12/30/2021 at 4:19 AM, ReaperAA said:

On 12/29/2021 at 7:06 PM, DwarfCleric said:

Also, mouse movement. It seems like DSDA is plagued by the HORRID mouse movement that (for whatever reason) SDL 2.0 brings to the table. (Zandronum users always complaining about this in their forum, and also being ignored...)

 

You are likely referring to the mouse lag that seems to sometimes exist in certain SDL2 ports. I am sure kraflab fixed the mouse though. But if its still not working for you, I would recommend turning OFF Vsync in options (that seems to fix it for pretty much every SDL2 port I have come across).

You can also try turning on Exclusive Fullscreen. For me, it's the difference between some weird floaty mouse movement and a much tighter, responsive movement.

Win32 build of dsda-doom 0.22.5:

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

So, is there no way to use VirtualMidiSynth now?

19 minutes ago, maxmanium said:

So, is there no way to use VirtualMidiSynth now?

You can use it with portmidi.

I've been away from the community for a little while but have been doing my annual "what's new in source ports?" review, and am really excited by DSDA-Doom. Once the Heretic and Hexen support matures a little more I can easily see this being my go-to for everything. Apologies if this has already been asked, but I was wondering if there are any plans to bundle the widescreen assets from Widepix for the supported games at any point? Would be fantastic to have Heretic and Hexen weapon sprites that aren't cut off in widescreen resolutions, assuming this wouldn't mess with anything.

On 1/2/2022 at 9:35 AM, kraflab said:

Updated to v0.22.5

For some reasons this new version runs a bit in slow motion on my computer, I checked that it was at "100%" speed. I have installed the new version in a new folder with a new cfg and I still get the same problem.  It fixed itself by restarting the computer...

@kraflab Thank you for fixing the autoswitch logic -- that always bugged me about playing Boom maps. That said, does that mean new -cl9 demos will no longer sync in other ports when it's disabled? Just wondering.

Boom's weapon swapping takes place outside the demo format. The port basically injects commands on your behalf. That means that changing how and when those injections take place will not affect demo compatibility.

On 1/2/2022 at 9:35 AM, kraflab said:

Updated to v0.22.5

 

KD completed a deep regression test, so my confidence that 0.22 hasn't broken demo sync is very high right now. I would appreciate it if more runners could put it through its paces as well.

 

That said, this release has some big changes related to music. Please let me know if you have any weird audio problems or new crashes. If you currently have sdl set as your midi player, I recommend switching to fluidsynth (the new default). Releases now include the same soundfont gzdoom uses as it's small and satisfactory, but you can still use your own. If you want to use the new one, you'll need to edit or reset your cfg file.

 

This update also edits boom's autoswitch behaviour. The way this is managed in the code is quite tricky, so let me know if this fix introduces some unexpected behaviour (autoswitch configuration only affects cl9+ due to demo sync constraints).

 

What's new:

• Revised music behaviour
  • Fluidsynth is the default midi player
  • Added default soundfont configuration
  • SDL is no longer available as a midi player
  • Fall back on SDL mixer for uncommon formats
    • E.g., FLAC now works while fluidsynth is selected
• Reexamine weapon autoswitch in cl9+
  • Fixed a bug where a weapon would swap multiple times
  • Added option to disable preemptive swap when running out of ammo
• Fixed demo playback warp consistency
• Fixed demo playback skipping for hexen

Download

There seems to be a problem with the "Roland SC-55 Music Packs" (FLAC) for every Doom-engine game, where a small part of the beginning of the audio tracks play twice in a row.

Secondly, the audio tracks don't loop perfectly in DSDA-Doom like they do in GZDoom, but simply restart after fading.

Lastly, I also had to export the audio tracks from the original .PK3-archive into a .WAD-archive to make them play in DSDA-Doom to begin with.

@kraflab I understand that there's probably a lot more work to do for Hexen support, but I just wanted to point out a couple of small bugs I've noticed during my own testing that you may or may not already be aware of:

- Picking up pieces of the fighter's fourth weapon cause the graphics added to the status bar to appear in the wrong place (located to the far left of the bar instead of as part of the picture of the final weapon to the right). This does not occur for the cleric or mage's fourth weapons.

The following two are very minor in the grand scheme of things, but I created some simple WADs to load in nash's widescreen assets and noticed a couple of minor bugs when including these:

- The extended status bar works, but doesn't display properly until the bar is is either increased or decreased in size, and then returned to normal.

- In the final few frames of the fighter's final punch animation (the third punch that extends out further), there is some glitching to the far right edge of the sprite. The actual sprite within the WAD extends much further than the point the glitching occurs. This doesn't happen when using the regular 4:3 cut-off assets.

I've tested my widescreen WADs in GZDoom and the above problems do not occur there, so I don't think there is any issue with the WADs themselves. The first problem with the fighter's fourth weapon graphic happens whether I use the widescreen assets or not.

Thanks for the reports

57 minutes ago, kraflab said:

Thanks for the reports

No problem. One other thing I'm sure you're already aware of (although I couldn't see it mentioned anywhere) is that in Hexen the title screen music doesn't play. All in-game music seems fine though. This is true in 0.22.5 and 0.21.3 at least.

This would obviously be for long-term development, but are there any plans to add support for Strife, Chex Quest and Hacx?

15 minutes ago, Dinoaur said:

This would obviously be for long-term development, but are there any plans to add support for Strife, Chex Quest and Hacx?

You can already play chex and hacx. No chance for strife.

14 minutes ago, Dinoaur said:

This would obviously be for long-term development, but are there any plans to add support for Strife, Chex Quest and Hacx?

dsda already supports chex quest 1 & 2 and Hacx (as a pwad for Doom 2). 

Oh, I didn't realise.

I just tested Chex Quest, and it works for Doom 1 at least.

2 hours ago, kraflab said:

You can already play chex and hacx. No chance for strife.

Strife does a lot of odd things, doesn't it? There's also no source code.