dsda-doom v0.25.6 [2023-01-15]

41 minutes ago, Dweller said:

 

I see. Is it possible to make the fullscreen hud from 0.24 with this method? 

It should be but which one are you taking about? in 0.24 there were a bunch of options IIRC.

Just now, Ramon_Demestre said:

 

It should be but which one are you taking about? in 0.24 there were a bunch of options IIRC.

The default fullscreen one, I think. It looked kinda similar to GZDoom and had the armor sprite.

I will try to replicate it, should not be hard.

here we go:

doom full
big_health 4 21 bottom_left
big_ammo 95 19 bottom_left
big_armor 242 20 bottom_right
keys 311 1 top_right
render_stats 2 8 top_left
coordinate_display 2 8 top_left
line_display 98 8 top_left
command_display 198 48 bottom_right

The new hud format is more limited than the old one so it is not exactly the same, but close enough.

Feel free to fine-tune the coordinates.

1 minute ago, Ramon_Demestre said:

here we go:

doom full
big_health 4 21 bottom_left
big_ammo 95 19 bottom_left
big_armor 242 20 bottom_right
keys 311 1 top_right
render_stats 2 8 top_left
coordinate_display 2 8 top_left
line_display 98 8 top_left
command_display 198 48 bottom_right

 

The new hud format is more limited than the old one so it is not exactly the same, but close enough.

Feel free to fine-tune the coordinates.

Thank you, I really appreciate it!

So, the HUD works fine, but it seems that the health/armor sprites for REKKR: Sunken Land, HACX, and Chex Quest are larger than Doom's and end up going past the bottom of the screen. Is there a good fix for it without editing the hud file? 

Unfortunately the coordinates must be manually adjusted for each game,

You can increase the Y position for big_health/ammo/armor.

v0.25.6 for Debian-based distros:

[old, removed]

If you want to autoload a hud file, just rename the hud text file file to "DSDAHUD.lmp" and put in in the desired autoload folder.

Hi all,

I think I am missing something so was looking for some help. I have been using DSDA-Doom on Windows lately and love it but hit an issue recently when I started using version 0.25.4. I launch the port and play doom as expected but if I switch application (alt+tab) the inputs remain bound to DSDA-Doom.

More specifically:

• When I launch version 0.24.3 I can switch applications (like hop to Chrome and visit Doomworld), the port minimises to the background and my inputs (mouse and keyboard) move to the application I have switched to

• When I launch version 0.25.4 (on exactly the same system and in exactly the same way) I can switch applications but my inputs (mouse and keyboard) remain bound to DSDA-Doom, i.e., I cannot type into the Chrome search bar, hitting control causes my weapon to fire and the mouse flickers (even when I am in the other application and the port is minimised). A noticeable difference is that launching DSDA-Doom 0.25.4 results in a persisting command window appearing (see below for the contents of the window - this is not there for version 0.24.3 or does not stay open whilst the port is running). Interacting with other applications returns to expected behaviour when DSDA-Doom is closed

Anyway, is this expected behaviour, have I missed something like a setting/config change or have I set up an incorrect version of the port for my needs? I miss being able to hop about applications whilst the port is still running in the background.

Additional System and Launch Details:

What the command window for v0.25.4 shows:

EDIT - Update:

For anyone else that has faced this issue I did not find out why it happens for me but I have updated to v0.25.6 and this works fine. Switching between them I encounter the issue on v0.25.4 but not on either v0.24.3 or 0.25.6. I am good to move on with v0.25.6 so will not look into this any more. Great port!

Omg this port supports 320x200 resolution!!!  This was too technologically advanced for prboom-plus 2.5.1.3.  You guys are revolutionary.  (context: every week I find something new that I like in this port :) - a really clean-ass port.)

Just wonder why demo attempts number not stored in .lmp footer. Will be nice to see it while playbacking.

With less importance will be nice to have overall time of all previous attempts summarized.

1 hour ago, NoisyVelvet said:

320x200 resolution!!!  This was too technologically advanced for prboom-plus 2.5.1.3

AFAIK it always be in prboom port line, at least for software exe.

Would you please consider readding

armor_red                       
armor_yellow                      
armor_green

?

I'd really like to set up custom armor number colors, like I could before 0.25. Atm, this is my only gripe, the new Indexed renderer is pretty awesome.                  

Hey there, love this port and the new release.  Only minor nagging issue I've had is that for me, as soon as I hit use to advance from the stats screen, it goes to the next map name and wipes instantly.  This means it's usually not long enough to read, especially if there's a mapper name, which is pretty annoying when recording vids as I have to keep the text file or whatever open to read them.  However, a few people have said they don't get this issue so I'm confused.  Had this issue in the last release and the new one as well.

Was told a demo file might help so this is one in vanilla doom 2: intermissionbug.zip .  Hopefully that is correct as I don't really record demos.  And every youtube video I've made with DSDA has the same issue.  Hopefully I can get a fix, thanks.

5 hours ago, Hitherto said:

AFAIK it always be in prboom port line, at least for software exe.

Technically it supported it but it was broken (EDIT: In monitors with aspect ratios other than 4:3), I reported it on doomworld and Fabian was kind enough to fix it for the community :)

1 hour ago, El juancho said:

Technically it supported it but it was broken, I reported it on doomworld and Fabian was kind enough to fix it for the community :)

On 4:3 laptop I had no problems with it. Thanks for info.

---

1 hour ago, sandwedge said:

Only minor nagging issue I've had is that for me, as soon as I hit use to advance from the stats screen, it goes to the next map name and wipes instantly.

Not instantly, but very short indeed. But that is vanilla behavior, not a bug.

22 minutes ago, Hitherto said:

Not instantly, but very short indeed. But that is vanilla behavior, not a bug.

Ah ok thanks.  Not that familiar with vanilla obviously, and apparently nobody I asked realized what I was talking about lol.  Sorry about that.  I dunno if a slower transition screen, or staying until hitting use again, would ever be considered as a quality of life feature, but I understand if that's not really a priority.  It would definitely be nice for stuff with mapinfo support that has map names, author names and even occasionally text that comes up there though.

1 hour ago, sandwedge said:

 

Ah ok thanks.  Not that familiar with vanilla obviously, and apparently nobody I asked realized what I was talking about lol.  Sorry about that.  I dunno if a slower transition screen, or staying until hitting use again, would ever be considered as a quality of life feature, but I understand if that's not really a priority.  It would definitely be nice for stuff with mapinfo support that has map names, author names and even occasionally text that comes up there though.

most vanilla wads probably have all that in mind to look at at the end. :D but yeah just idle before pressing use to advance to the next screen

I assume this behavior is just leftover from doom1 code, where some short-but-enough animation is shown.

Imho will be nice to have it until key pressed, like zdoom does, but not as default option.

Just now, Hitherto said:

I assume this behavior is just leftover from doom1 code, where some short-but-enough animation is shown.

 

Imho will be nice to have it until key pressed, like zdoom does, but not as default option.

The first game actually stayed on the screen longer to flash the "YOU ARE HERE" graphic. They probably took out the delay in Doom II due to the lack of a map on the intermission screen.

Probably this better suited for thread like "crazy features that never will never get added" but I would really like advanced chasecam feature, with automated motion patterns (around/above helicopter-style) and some fixed hotkeyed points of view.

Hello everyone. 

I am new to doom in general and its sourceports in particular, so forgive me for asking probably obvious question. As far as I know, dsda-doom is an advanced and upgraded iteration of Prboom+. It is claimed that dsda-doom possesses majority (if not all) of Prboom+'s features. But I have consistently failed to find FOV settings. At the same time, Prboom+ does have it. Is it my blindness or dsda-doom actually does not have FOV settings?

Inb4, I am using 0.25.6 version with OpenGL renderer. 

8 minutes ago, MrHellstorm17 said:

Hello everyone. 

I am new to doom in general and its sourceports in particular, so forgive me for asking probably obvious question. As far as I know, dsda-doom is an advanced and upgraded iteration of Prboom+. It is claimed that dsda-doom possesses majority (if not all) Prboom+'s features. But I have consistently failed to find FOV settings. At the same time, Prboom+ does have it. Is it my blindness or dsda-doom actually does not have FOV settings?

Inb4, I am using 0.25.6 version with OpenGL renderer. 

"gl_render_fov" in the config file, I guess it got removed from the menus amidst all the other reshuffling of the options.

11 hours ago, Shepardus said:

"gl_render_fov" in the config file, I guess it got removed from the menus amidst all the other reshuffling of the options.

Thank you very much.

By the way, is skybox supposed to move like that? Like, to the opposite direction with respect to mouse movement. It gives me a bit of dizzy feeling. Is it an original doom engine feature or incorrect rendering settings?

21 minutes ago, MrHellstorm17 said:

By the way, is skybox supposed to move like that? Like, to the opposite direction with respect to mouse movement. It gives me a bit of dizzy feeling. Is it an original doom engine feature or incorrect rendering settings?

No, that's not normal at all. The original engine (and DSDA-Doom/PrBoom+'s software renderer) do a slight (barely noticeable at 90° FOV) perspective warping of the sky that compresses it in the center and stretches it near the edges of the screen; this effect is completely absent from the OpenGL renderer (this bug appears to have been inherited from PrBoom+).

This midi file fails to run with dsda-doom-0.25.6, giving the following error: unknown MIDI event type: 0xfe

Is there something off or malformed with the midi file itself that can be fixed, or is this a bug with the port? It replaces D_RUNNIN.

I can confirm it works in PRBoom and GZdoom.

BrokenMidi.zip

@Captain Toenail The MIDI file parser used in most source ports aborts if illegal events are detected. That MIDI file has at least one illegal event (0xFE) and is also missing end of track events. You can try repairing it by opening and saving it with Sekaiju.

My favorite source port !  Love the indexed look!! Would be cool to have brightmaps on switches and some items, just like crispy and woof, dont know how hard it would be to do? 

@ceski Excellent that fixed it, thank you!

Where is stored or how to enable program log file (like output.txt in prb+/choco)?