dsda-doom source port [v0.24.3]

[El Juancho]

40 minutes ago, Artbor said:

Bit of an odd/niche question, but currently is there a way to have the game freeze or mute when I alt tab?

It's a habit of mine to get distracted often when playing Doom (or any game for that matter) so I'll take occasional breaks to do something else on my PC. Some full screen apps mute themselves when alt tabbed but I mute DSDA Doom manually.

When you pause in DSDA-Doom the game stops and mutes itself :)

 

[Renbot]

@El juancho

thank you very much, this will do

[liPillON]

hi, I'm interested in creating a new custom hud layout

it should be as simple as creating a new "-PRBHUD-" lump, adding it to a .wad file and load it using the -file parameter, right? 

 

is there some documentation about the various elements we can toy with in the lump?

 

[Maribo]

5 hours ago, Artbor said:

Bit of an odd/niche question, but currently is there a way to have the game freeze or mute when I alt tab?

Bind a Pause key and press it before you alt tab.

edit: sorry for extra post, Doomworld took me to the bottom of page 40 instead of page 41. Juancho already covered it.

Edited March 22, 2022 by Maribo

[liPillON]

On 3/22/2022 at 2:52 PM, Delfino Furioso said:

it should be as simple as creating a new "-PRBHUD-" lump, adding it to a .wad file and load it using the -file parameter, right? 

 

I've tried this and it does not seem to be supported right now, the only way to modify/add hud layouts is to edit the lump embedded in dsda-doom.wad (which is not really ideal)

prboom+ behave the same, so I guess I should ask upstream for this feature to be implemented?

 

 

[PKr]

Hey!

 

I am trying to solve the mouse related problem in DSDA-Doom that I have:

I have managed to apply the suggested fix to dsda-doom successfully, and it solves the problem completely... Except it doesn't work everytime you launch the game. @fabian told me that there was a function in PrBoom+ to get the fractional tic value, and it solved the problem in PrBoom+.

 

Could you please tell me if there is similar function in DSDA-Doom?

Edited March 28, 2022 by PKr

[Shepardus]

A quick code search finds me a function called dsda_TickElapsedTime, you can check to see if that does what you want.

[PKr]

8 hours ago, Shepardus said:

A quick code search finds me a function called dsda_TickElapsedTime, you can check to see if that does what you want.

That was... Obvious. 😅 Thank you.

 

The function itself turned out to be rather useless however. It's just not as accurate as the similar function in PrBoom+. So it's barely an improvement over the mouse stuttering I have in DSDA.

 

NVM, I just can't do math...

 

Here is a 100% working fix for mouse stuttering in DSDA:

 

i_video.c

Spoiler

+#include "dsda/time.h"
  
+static void SmoothMouse(int* x, int* y)
+{
+    static int x_remainder_old = 0;
+    static int y_remainder_old = 0;

+    int x_remainder, y_remainder;
+    fixed_t correction_factor;

+    *x += x_remainder_old;
+    *y += y_remainder_old;

+    correction_factor = FixedDiv(dsda_TickElapsedTime(), dsda_TickElapsedTime() + FRACUNIT/2);

+    x_remainder = FixedMul(*x, correction_factor);
+    *x -= x_remainder;
+    x_remainder_old = x_remainder;

+    y_remainder = FixedMul(*y, correction_factor);
+    *y -= y_remainder;
+    y_remainder_old = y_remainder;
+}

static void I_ReadMouse(void)
{
  if (mouse_enabled && window_focused)
  {
    int x, y;

    SDL_GetRelativeMouseState(&x, &y);
+    SmoothMouse(&x, &y);

 

 

Edited March 29, 2022 by PKr

[Ramon_Demestre]

That is strange, the dsda_TickElapsedTime() uses the clock_gettime() timing function and should be microsecond accurate instead of the 1-2 milliseconds inaccuracy of the SDL_GetTicks() that is used by I_TickElapsedTime() in prboom+.

dsda-doom changed all timing function to gain accuracy, I guess the implementation of clock_gettime() depends on the os and on the complier, but I hardly see how it could be worse than the SDL_GetTicks(), do you have any idea?

 

Edit: Ok I see you figured it out, congratulations!

This is a very nice improvement, I always used to turn OFF vsync but I guess It can be turned on now.

Edited March 30, 2022 by Ramon_Demestre

[Ramon_Demestre]

Here is a Win32 build of latest dsda-doom.exe (only) that has the fix, just to try.

This is not an official release...

dsda-doom0.24.2-win32exe-PKr-smoothmouse.7z

[GoneAway]

Could you open a PR with your change? @PKr

[PKr]

1 hour ago, kraflab said:

Could you open a PR with your change? @PKr

Uh, sorry, I already explained to fabian that I don't know how to use git... :D Could you please do this by yourself?

 

Here is a less lame code btw:

Spoiler

#include "dsda/time.h"

static void SmoothMouse(int* x, int* y)
{
    static int x_remainder_old = 0;
    static int y_remainder_old = 0;

    int x_remainder, y_remainder;
    fixed_t correction_factor;

    *x += x_remainder_old;
    *y += y_remainder_old;

    const fixed_t fractic = dsda_TickElapsedTime();

    correction_factor = FixedDiv(fractic, fractic + FRACUNIT/2);

    x_remainder = FixedMul(*x, correction_factor);
    *x -= x_remainder;
    x_remainder_old = x_remainder;

    y_remainder = FixedMul(*y, correction_factor);
    *y -= y_remainder;
    y_remainder_old = y_remainder;
}

static void I_ReadMouse(void)
{
  if (mouse_enabled && window_focused)
  {
    int x, y;

    SDL_GetRelativeMouseState(&x, &y);
    SmoothMouse(&x, &y);

 

P.S. Also, this is @mikeday's patch, not mine. So all credits go to him.

[GoneAway]

Alrighty, I'll take care of it soon then

[mikeday]

@PKr No problem! You deserve credit too. You were the one who reported the issue and also helped out tremendously with testing.

 

Just curious - why FRACUNIT / 2 for dsda-doom?

 

 

Edited March 30, 2022 by mikeday

[GoneAway]

Let me know if the division by 2 is correct and I can make a release :^)

[PKr]

3 hours ago, mikeday said:

@PKr No problem! You deserve credit too. You were the one who reported the issue and also helped out tremendously with testing.

 

Just curious - why FRACUNIT / 2 for dsda-doom?

Apparently dsda_TickElapsedTime() works differently from I_TickElapsedTime() in PrBoom+ or I_GetTimeMS() * TICRATE % 1000 * FRACUNIT / 1000; in Crispy Doom.

 

When using fractic=dsda_TickElapsedTime(); correction_factor = FixedDiv(fractic, fractic + FRACUNIT); DSDA still stutters when using mouse to turn camera around. Just to reproduce the issue, go to e3m1. When in starting area, try to swipe mouse in fluid motions while strafing left or right. Focus on tree sprites and ground textures. The stuttering will still be there, although not as apparent as without the patch. Not really sure whether you will notice it or not though, since I am extremely sensitive to all kinds of framepacing and interpolation related artifacts. So, maybe you won't even see any difference.

 

After that I tried to manipulate correction_factor value in different ways to find a solution. Experimentally I found out that FRACUNIT / 2 eliminates the problem completely.

 

So, quite honestly, I don't understand dsda_TickElapsedTime() that well to explain why 1/2 of FRACUNIT is needed to fix the issue in DSDA Doom, but it 100% fixes the issue.

 

P.S. Btw, after noticing that, I went back to Crispy Doom and PrBoom+ to see whether I simply missed something, but no, the mouse movement is completely smooth there without FRACUNIT/2.

Edited March 30, 2022 by PKr

[GoneAway]

Updated to v0.24.3

 

What's new:

• Improved automatic keyframe timeout behaviour
• Fixed a crash caused by saving the game state after an intercept overrun
• Added mouse stutter correction option (on by default) (@PKr / @mikeday)

Download

[Ramon_Demestre]

Usual win32 build of dsda-doom 0.24.3

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

[Maribo]

v0.24.3 for Debian-based distros: dsda-doom-0.24.3.zip

alastortenebris did have a point that a Launchpad PPA might be better overall for .deb distribution, but I'll have to look more into it since I have no experience with distributing software through those channels.

[mikeday]

7 hours ago, PKr said:

After that I tried to manipulate correction_factor value in different ways to find a solution. Experimentally I found out that FRACUNIT / 2 eliminates the problem completely.

You weren't too far off actually! I just looked at the dsda-doom timing functions. I believe the FRACUNIT / 2 should actually be 1000000 / TICRATE. (That is, the number of microseconds per gametic.) This is about 28571. Half of FRACUNIT is 65536 / 2 = 32768.

 

I'll submit a quick PR.

 

[PKr]

10 hours ago, mikeday said:

You weren't too far off actually! I just looked at the dsda-doom timing functions. I believe the FRACUNIT / 2 should actually be 1000000 / TICRATE. (That is, the number of microseconds per gametic.) This is about 28571. Half of FRACUNIT is 65536 / 2 = 32768.

 

I'll submit a quick PR.

Interesting. After not seeing any difference between 28571 and 32768 whatsoever I've checked how huge can an error margin be here. It seems like anything between ~25000 and ~36000 is imperceivable and appears as a completely smooth motion.

 

P.S. Do you have any interest in fixing interpolation implementation in Eternity Engine by any chance? I have checked the code already, and it seems like the problem is R_GetLerp() in r_main.cpp which returns the wrong value. I have tried to compensate i_haltimer.GetFrac(), and I can confirm that it makes the game significantly much smoother (aside from the mouse which probably will have the similar issue). Sadly, as you might have already guessed, my coding skills are non-existent so I can't write the precise timing compensation to completely eliminate the issue, and the approximation is not enough to fix it in Eternity Engine. :(

Edited March 31, 2022 by PKr

[ginc]

On 7/31/2021 at 9:34 AM, kraflab said:

Weapon swapping is based on the input being held down when the game engine processes a frame. It's actually an error in old versions of pr+ that allows you to use the mouse wheel for this class of input.

 

So in other ports I have mousewheel up and down bound to specific weapon slots, but to my dismay it seems not to work in dsda-doom (0.24.3 at the time of this post). I'm able to bind it in the menus (see pic) but it does nothing ingame. Mousewheel does work for automap zoom, and it does work when bound to next/previous weapon.

 

Is this Working As Intended^TM, or is there some option I need to enable/change, or is there a fix coming?

Edited April 2, 2022 by ginc

[L0l1nd3r]

I'm curious about a possible bug in rekkr while using the Staff of Rune Explosion against Mean Jackalopes doesn't always update the kill count correctly. I would be missing kills on exit. The Kill count works correctly with all other weapons and in GZDoom. I threw together a test map to recreate the conditions: KillCountTest.7z

Edit: The map is in Doom2 as rekker uses a lot of code pointers to bring the extra doom2 assets over to Ultimate Doom. Just use the rocket launcher, any other weapon may cause a crash.

Edited April 2, 2022 by L0l1nd3r
Edit what map format test map is in.

[Kappa971]

I would like to report a strange problem with Intel GMA 4500 MHD integrated graphics and DSDA-Doom OpenGL render in Linux (Debian and Ubuntu).
Selecting the OpenGL renderer, vsync and uncapped framerate enabled, you will notice a strange phenomenon that resembles the trails effect of GTA 3! This doesn't happen in any other OpenGL game, not even in PrBoom-Plus, and in any other PC that I have tried (unfortunately I don't have another PC with Intel graphics).
This phenomenon seems to be accentuated when 62 fps is hit... I don't know the other Intel chips, but in this one when vsync is enabled, the fps counter shows 62 fps in all the games I have tried, despite the monitor refresh rate indicated is 60hz. As mentioned, PrBoom-Plus syncs correctly at 62fps without that weird effect.
If that doesn't happen with other Intel integrated graphics, no problem, as you can imagine this isn't my gaming PC.

[GoneAway]

Does switching the light mode do anything? The main difference between the ports with opengl is probably the light mode options.

[Kappa971]

1 hour ago, kraflab said:

Does switching the light mode do anything? The main difference between the ports with opengl is probably the light mode options.

The problem is present with both "glboom" and "shaders" light modes. PrBoom-Plus also has these light modes and they work fine (with this Intel graphics, "glboom" works best because it's lighter)

[boom_compatible]

13 hours ago, Kappa971 said:

I would like to report a strange problem with Intel GMA 4500 MHD integrated graphics and DSDA-Doom OpenGL render in Linux (Debian and Ubuntu).
Selecting the OpenGL renderer, vsync and uncapped framerate enabled, you will notice a strange phenomenon that resembles the trails effect of GTA 3! This doesn't happen in any other OpenGL game, not even in PrBoom-Plus, and in any other PC that I have tried (unfortunately I don't have another PC with Intel graphics).
This phenomenon seems to be accentuated when 62 fps is hit... I don't know the other Intel chips, but in this one when vsync is enabled, the fps counter shows 62 fps in all the games I have tried, despite the monitor refresh rate indicated is 60hz. As mentioned, PrBoom-Plus syncs correctly at 62fps without that weird effect.
If that doesn't happen with other Intel integrated graphics, no problem, as you can imagine this isn't my gaming PC.

 

I had something like that, and DRI 3 was the culprit.

Forcing DRI 2 + UXA solved the problem

Spoiler

Inside /usr/share/X11/xorg.conf.d/00-intel.conf
---------------------------------------------------------
Section "Device"
        Identifier  "Card0"
        Driver      "intel"
#        Driver      "modesetting"
#        Option      "AccelMethod" "EXA"
        Option      "AccelMethod"  "uxa"
        Option "DRI" "2"
EndSection
---------------------------------------------------------

modesetting cap to 60fps here
 

 

[Kappa971]

18 minutes ago, boom_compatible said:

 

I had something like that, and DRI 3 was the culprit.

Forcing DRI 2 + UXA solved the problem 

  Reveal hidden contents

Inside /usr/share/X11/xorg.conf.d/00-intel.conf
---------------------------------------------------------
Section "Device"
        Identifier  "Card0"
        Driver      "intel"
#        Driver      "modesetting"
#        Option      "AccelMethod" "EXA"
        Option      "AccelMethod"  "uxa"
        Option "DRI" "2"
EndSection
---------------------------------------------------------

modesetting cap to 60fps here
 

 

I don't know what exactly these tweaks do, and I don't want to apply them as other games (including PrBoom-Plus) are working fine, so there must be something wrong with DSDA-Doom. Thanks anyway.

Edited April 4, 2022 by Kappa971

[RN_Jesus]

Using 24.1 windows nothing ever crashed and/or visually glitched for me ever... then just downloaded the 24.3 32bit and got some crazy fly out of the map to crash w/ visual garbage glitches across the screen tonight playing c-shock map03 on comp 9. And another error playing cybercontrol_lit.wad map31. Idk if that has anything to do w/ plutonia iwad for c-shock. 
Also noticed in Iamevil1.wad on comp lvl 2 dsda seems to wake up the cyber on player start and this never happened under prboom-plus-2.5.1.4 (the version used in

Ancalagon's Demo using PRBoom v2.5.1.4cl2 2:43.20) The map has a super high elevator and I was wondering if dsda would handle that line of sight differently. I was going to try and beat his time for the memes but feel its not working the way it did in his demo. 

 

 

Edited April 4, 2022 by RN_Jesus

[maxmanium]

I remember reading at some point on this thread (I think) that there were plans to have spectre fuzz drawn as it is in 320x200, or have it be an option or something. Is that still in place?