Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
kraflab

dsda-doom source port [v0.24.3]

Recommended Posts

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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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:
 

Spoiler

SetRatio: storage aspect ratio 16:9
SetRatio: assuming square pixels
SetRatio: display aspect ratio 16:9
SetRatio: gl_ratio 2.133334
SetRatio: multiplier 3/4
ST_Init: Init status bar.
G_DoPlayDemo: playing demo with Doom/Doom2 v1.9 compatibility
FINISHED: MAP27
Exit Sequence[0]: I_EssentialQuit (0)
Exit Sequence[1]: gld_CleanMemory (0)
Exit Sequence[1]: gld_FreeScreenSizeFBO (0)
Exit Sequence[1]: gld_ShutdownDetail (0)
Exit Sequence[1]: I_ShutdownGraphics (0)
Exit Sequence[1]: I_ShutdownSDL (0)
Exit Sequence[2]: I_Quit (0)
dsda-doom v0.22.4 (https://github.com/kraflab/dsda-doom/)

 

 

Edit: oops nevermind, didnt see the last replies

Share this post


Link to post
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?

Share this post


Link to post

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.

Share this post


Link to post

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?

Share this post


Link to post
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.

Share this post


Link to post

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

 

DSDA_error_launcher.png.27884ec3d5dfa75c515c1aadef1f16b7.png

 

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.

Share this post


Link to post

@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.

Edited by ReaperAA

Share this post


Link to post
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.

Share this post


Link to post
19 minutes ago, maxmanium said:

So, is there no way to use VirtualMidiSynth now?

You can use it with portmidi.

Share this post


Link to post

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.

Share this post


Link to post
Posted (edited)
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...

Edited by El juancho

Share this post


Link to post

@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.

Share this post


Link to post

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.

Share this post


Link to post
Posted (edited)
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.

Share this post


Link to post
Posted (edited)

@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.

Share this post


Link to post
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.

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post
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). 

Share this post


Link to post

Oh, I didn't realise.

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

Share this post


Link to post
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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×