dsda-doom source port [v0.24.3]

[Marisa the Magician]

Was wondering where I could report this but... I haven't been able to build dsda-doom from source on Linux for several months now. The compiler output looks like this:

/home/marisa/.cache/paru/clone/dsda-doom-git/src/dsda-doom/prboom2/src/MUSIC/dumbplayer.c:74:27: error: unknown type name ‘off64_t’
   74 | #define DUMB_OFF_T_CUSTOM off64_t
      |                           ^~~~~~~
In file included from /home/marisa/.cache/paru/clone/dsda-doom-git/src/dsda-doom/prboom2/src/MUSIC/dumbplayer.c:78:
/usr/include/dumb.h:136:1: error: static assertion failed: "dumb: off_t must be 64bit"
  136 | _Static_assert(sizeof(dumb_off_t) >= 8, "dumb: off_t must be 64bit");
      | ^~~~~~~~~~~~~~

 

[PBeGood]

2 hours ago, Marisa the Magician said:

Was wondering where I could report this but... I haven't been able to build dsda-doom from source on Linux for several months now. The compiler output looks like this:

 

Seems that off64_t made a new victim. I had the same problem on MacOS.

 

Try this:

1. Go to prboom2/src/MUSIC/dumbplayer.c line 71

2. Change #elif defined(__APPLE__) to #elif defined(__APPLE__  || __linux__)

[mikeday]

5 hours ago, Dinoaur said:

 

Do you think you might get a chance to look at FLAC-playback as well? I reported a few issues I've had with it a while back, and it would be great if you could get it working in future releases.

Post #1:

Post #2:

Thanks!

These aren't dsda-doom issues, but rather problems with SDL Mixer. I submitted patches to SDL Mixer some time ago to fix both the FLAC initial stutter and to add FLAC looping support. Once the next release of SDL Mixer emerges (I think it will be 2.6) and dsda-doom picks it up these should be resolved.

 

[fabian]

2 hours ago, PBeGood4 said:

Seems that off64_t made a new victim. I had the same problem on MacOS.

We could probably just do

#define DUMB_OFF_T_CUSTOM int64_t

on every platform and be done with it. 

[Dinoaur]

1 hour ago, mikeday said:

These aren't dsda-doom issues, but rather problems with SDL Mixer. I submitted patches to SDL Mixer some time ago to fix both the FLAC initial stutter and to add FLAC looping support. Once the next release of SDL Mixer emerges (I think it will be 2.6) and dsda-doom picks it up these should be resolved.

 

Thanks for the quick response, it'll be great once that happens!

[siege cunt]

On 6/17/2022 at 10:28 AM, kraflab said:

A couple other people had a save corruption problem on jumpwad map 7, so something is definitely messed up. It's a strange error, because it means that something in the save file is looking for an object that doesn't exist in the save file (like if it stored a monster that is targeting a monster that doesn't exist). It either means there is an error in choosing what things to put into the save file, or some kind of edge case in parsing the file itself. I haven't looked into it yet but thanks for the report - it helps to confirm specifically map 7 is where the problem happens.

 

On 6/16/2022 at 10:31 AM, El Inferno said:

Not sure if it's worth bringing up here, but I've got a corrupted savegame while playing jumpwad map07 on dsda 0.24.3 (and it costed me an hour of progress :( ). I think it's the first time I got one so I'm not sure how frequently they happen and if it's something wad-specific.

dsda-doom-savegame999.zip

 

I've known about another bug for a while with save states that seems easily repeatable and may give some hints as to what's going on here?  I avoided saying anything here before, hoping someone else had better info, but since there's silence, I'll say what I know, though meager.

 

The bug is specific to 20x7 map 9 and I triggered it first long ago and mentioned it in rayzik's jump.wad stream.  It can result in a situation like this, which I think is normally impossible:

 

to repeat this very easily now, here's what i did:

 

- used cheats to quickly get to these three switches in 20x7 map 9 (i mention it in case it seems to matter, but i triggered it without cheats in the past).

- i hit the three switched and then stood underneath the gates.

- i let one close and let the other two bounce on my head.  i mention this because the bug seems to be that some detailed states can persist across rewinds.

- if i then rewind to before any switch presses, i get to this situation, where the skull eyes glow but the gates are closed.  afaik this scenario is impossible without save states.

 

when i originally triggered this (casually playing through 20x7 not long after dsda got rewind), i did it in another way (i think i rewinded some pathetic failure to press all three switches), but still got this effect.  the bottom line is that there are some types of complex linedef/tag/? behavior that are not properly reverted with dsda rewind.  i guess jump.wad just makes this a lot more pronounced.

 

sorry in advance if this does not help at all, and for spamming the thread.

[GoneAway]

Thanks, this kind of stuff is very helpful indeed

[GoneAway]

Looks like this is an artifact of the buttonlist array where doom stores the timer for switch texture changes. That list doesn't get stored in save files (this affects regular saves in the same way). The minimum case to reproduce this is to just press the switch, save the game, and load the game (while the eyes are still glowing). Then the texture is stuck. It doesn't look like it affects the game at all though, it's just cosmetic.

[siege cunt]

44 minutes ago, kraflab said:

Looks like this is an artifact of the buttonlist array where doom stores the timer for switch texture changes. That list doesn't get stored in save files (this affects regular saves in the same way). The minimum case to reproduce this is to just press the switch, save the game, and load the game (while the eyes are still glowing). Then the texture is stuck. It doesn't look like it affects the game at all though, it's just cosmetic.

 

dang, sorry, i was really hoping this helped with the jump.wad crashes.  sorry i didn't debug it further.

 

thanks for the great source port!

[gwain]

I'm not sure if I should post this here or a separate thread but here goes:

dsda doom crashes (as does every other port) when I get to this spot in my map

Spoiler

but the problem is it just crashes without telling me the problem

these are my settings and I'm kind of perplexed to what the problem may be

[Shepardus]

39 minutes ago, gwain said:

dsda doom crashes (as does every other port)

If every port crashes, then it's not specific to dsda-doom, but rather with your wad. You'd probably be better off asking in the Doom Editing subforum, and also share the wad so people can test for themselves.

[gwain]

10 hours ago, Shepardus said:

If every port crashes, then it's not specific to dsda-doom

but why does it not tell me the error

[GoneAway]

The port can only explain an error if it's anticipated and caught by the software. A generic exception like a segmentation fault for instance doesn't have the context in a regular release build to explain itself in a helpful way. There are lots of ways dehacked files can crash due to how flexible the code pointers are and a lack of comprehensive validations (as an example). If you post your wad either here or in the editing section, someone may be able to see the issue right away. If you still have a problem let me know and I will figure it out on the code side.

[Shepardus]

13 hours ago, gwain said:

but why does it not tell me the error

If you're not doing so already, run the port from the command-line and keep the terminal open, since any error messages would be printed there (though as kraflab said, if it's a generic signal 11/segfault, that doesn't tell you much).

[PBeGood]

Without posting the wad, it is impossible to tell what the problem is. But it might be related to improper use of dehacked enemies.

[PKr]

Can I somehow make crosshairs render without increasing in size at sub 400p resolutions? For example at 426x200 the dot crosshair appears to be x4 bigger compared to other resolutions. On top of that crosshair scale options don't do anything when playing at 200p.

 

For the sake of comparison in Woof crosshair remains small even when turning off high resolution (playing at 200p).

[GoneAway]

1 hour ago, PKr said:

Can I somehow make crosshairs render without increasing in size at sub 400p resolutions? For example at 426x200 the dot crosshair appears to be x4 bigger compared to other resolutions. On top of that crosshair scale options don't do anything when playing at 200p.

 

For the sake of comparison in Woof crosshair remains small even when turning off high resolution (playing at 200p).

If "scale crosshair" is on, then the crosshair increases in size with resolution to cover the same fraction of the screen as it does at low res. If it's off, then it looks "smaller" at high res because it isn't being scaled up to match. But at 200p, it is at the base size, so the scale factor is 1 (no difference if option is on or not). It looks like it's all working correctly on my end. For the super low resolution, it could be worth adding a 1 pixel dot variant. I think the existing one is 3x3.

[PKr]

11 minutes ago, kraflab said:

If "scale crosshair" is on, then the crosshair increases in size with resolution to cover the same fraction of the screen as it does at low res. If it's off, then it looks "smaller" at high res because it isn't being scaled up to match. But at 200p, it is at the base size, so the scale factor is 1 (no difference if option is on or not). It looks like it's all working correctly on my end. For the super low resolution, it could be worth adding a 1 pixel dot variant. I think the existing one is 3x3.

Ah... I am a moron. Thank you! Should've checked crosshair sprites in dsda-doom.wad instead of trying to fix a non-existent issue in a source code...

[PKr]

By the way, is Revenants desyncing demos a known issue? I have tried recording a demo file in chocolate doom multiple times now, and whenever I first meet Revenants the demo playback in dsda-doom/prboom+/woof breaks completely. Demos work properly in Chocolate Doom/Sprinkled Doom though.

 

So, apparently, almost everything desyncs between mentioned ports as soon as revenants shoot homing missiles no matter what source port is used to record demo, so don't bother answering that question...

Edited July 10, 2022 by PKr

[Never_Again]

On 7/10/2022 at 8:56 AM, PKr said:

By the way, is Revenants desyncing demos a known issue? I have tried recording a demo file in chocolate doom multiple times now, and whenever I first meet Revenants the demo playback in dsda-doom/prboom+/woof breaks completely. Demos work properly in Chocolate Doom/Sprinkled Doom though.

 

So, apparently, almost everything desyncs between mentioned ports as soon as revenants shoot homing missiles no matter what source port is used to record demo, so don't bother answering that question...

 

It's most likely a user error. There have been thousands of demos featuring Revenants' homing missiles recorded since the nineties, all of which play perfectly in prboom-plus, and almost certainly in DSDA-Doom and Woof. If you manage to record such a demo with Choco that plays back correctly in Choco but not in the other three ports the developers of those ports would be very interested to see it and to learn how you created.

[HackNeyed]

7 hours ago, Never_Again said:

 

It's most likely a user error.

 

Well count me in! I just made a demo with Sprinkled Doom 3.4.1 in Doom2 map18 where I go wake up a Revenant and tool around for a bit then kill it and head back to the starting area but it desyncs in Crispy/DSDA/Woof yet still plays fine in Sprinkled.

 

EDIT: I just compiled the latest Chocolate-Doom and it also desyncs like Crispy/DSDA/Woof. So I made a new demo with DSDA-Doom and it plays fine in Choco/Crispy/DSDA/Woof but not in Sprinkled-Doom. At the moment Sprinkled-Doom is the odd one out. If @PKr is having problems with Chocolate and Sprinkled maybe Chocolate had the problem and Sprinkled merged it in only for Chocolate to be fixed later.

 

EDIT2 So I compiled Chocolate-Doom from a month ago around when Sprinkled was last updated and another from 6 months ago but neither match Sprinkled-Doom's behaviour so @PKr can you please list exactly what version of Chocolate-Doom you used?

Edited July 12, 2022 by HackNeyed

[Doomkid]

I'm wondering if maybe just one of the ports in question isn't resetting gametics to 0 automatically as demo playback begins? That would explain why revenants in particular trigger the desync, but I'm just tossing out a wild guess.

[PKr]

2 hours ago, HackNeyed said:

 

Well count me in! I just made a demo with Sprinkled Doom 3.4.1 in Doom2 map18 where I go wake up a Revenant and tool around for a bit then kill it and head back to the starting area but it desyncs in Crispy/DSDA/Woof yet still plays fine in Sprinkled.

 

EDIT: I just compiled the latest Chocolate-Doom and it also desyncs like Crispy/DSDA/Woof. So I made a new demo with DSDA-Doom and it plays fine in Choco/Crispy/DSDA/Woof but not in Sprinkled-Doom. At the moment Sprinkled-Doom is the odd one out. If @PKr is having problems with Chocolate and Sprinkled maybe Chocolate had the problem and Sprinkled merged it in only for Chocolate to be fixed later.

 

EDIT2 So I compiled Chocolate-Doom from a month ago around when Sprinkled was last updated and another from 6 months ago but neither match Sprinkled-Doom's behaviour so @PKr can you please list exactly what version of Chocolate-Doom you used?

It would be hard to tell which version of chocolate doom I had, since I usually compile the latest dev builds... But there is no need to, as you are 100% right. I have tried recording separate demos in each of the mentioned source ports after reading your comment, and it is indeed sprinkled doom's demos that get desynced in other source ports all the time once revenants start shooting rockets.

[xX_Lol6_Xx]

I notified Gibbon through Discord, maybe he'll find the problem in Sprinkled-Doom

[HackNeyed]

4 hours ago, PKr said:

it is indeed sprinkled doom's demos that get desynced in other source ports all the time once revenants start shooting rockets.

 

Yep. I think I've narrowed it down. Sprinkled Doom 3.3.0 seems to work correctly (as in it desyncs like the other ports) however 3.4.0 and up only keep in sync with each other.

 

@xX_Lol6_Xx Thanks! If you want to pass along the info that it seems to have happened between 3.3.0 and 3.4.0 it might save him a little digging.

 

EDIT: Looks like its fixed by Gibbon in a commit about an hour ago on github. My testing shows its now fixed and in line with the rest of the ports.

Edited July 12, 2022 by HackNeyed

[PKr]

8 hours ago, HackNeyed said:

 

Yep. I think I've narrowed it down. Sprinkled Doom 3.3.0 seems to work correctly (as in it desyncs like the other ports) however 3.4.0 and up only keep in sync with each other.

 

@xX_Lol6_Xx Thanks! If you want to pass along the info that it seems to have happened between 3.3.0 and 3.4.0 it might save him a little digging.

 

EDIT: Looks like its fixed by Gibbon in a commit about an hour ago on github. My testing shows its now fixed and in line with the rest of the ports.

Yep, it seems like everything is working fine now. No idea why I thought chocolate doom synced with sprinkled demos properly though, as I have checked all my installed chocolate versions once again, and neither of them played v3.4.1 demos properly...

[hobomaster22]

I've noticed two problems with WeaponProjectile. First, is the hoffset parameter. Setting it to 4194304(64*65536) spawns the object in a seemingly random spot. For some reason it's subtracting 90 from the angle when calculating the x/y offset. Removing this line of code spawns the object 64 units in front of the player as expected. Maybe there is a reason for this, but it makes no sense to me at the moment:
https://github.com/kraflab/dsda-doom/blob/master/prboom2/src/p_pspr.c#L1252

Second, if you use WeaponProjectile to spawn something that doesn't have the MISSILE flag, the speed is incorrect. This is a strange dehacked quirk where the speed is only supposed to be fixed point if it has the MISSILE flag (lol dehacked?):
https://eternity.youfailit.net/wiki/DeHackEd_/_BEX_Reference/Thing_Block#Speed_.3D_.3Cnumber.3E

This creates an issue using decohack because if you create an object without the MISSILE flag and give it a speed of 8, the output in dehacked is 8 which ends up being 8/65536 in dsda.

 

MonsterProjectile seems to have these same issues looking at the code.

[GoneAway]

10 hours ago, hobomaster22 said:

First, is the hoffset parameter. For some reason it's subtracting 90 from the angle when calculating the x/y offset.

The "h" is "horizontal", as in left / right. So an offset of 10 should shift the starting location to the player's side by 10 units. The 90 degree rotation calculates that location.

[MTrop]

11 hours ago, hobomaster22 said:

Second, if you use WeaponProjectile to spawn something that doesn't have the MISSILE flag, the speed is incorrect. This is a strange dehacked quirk where the speed is only supposed to be fixed point if it has the MISSILE flag (lol dehacked?):
https://eternity.youfailit.net/wiki/DeHackEd_/_BEX_Reference/Thing_Block#Speed_.3D_.3Cnumber.3E

This creates an issue using decohack because if you create an object without the MISSILE flag and give it a speed of 8, the output in dehacked is 8 which ends up being 8/65536 in dsda.

 

MonsterProjectile seems to have these same issues looking at the code.

 

This is entirely expected, at least to me - trying to use a thing that is not supposed to be used as a MISSILE would result in a misread of speed, since a fixed-point speed value if MISSILE is correct both in Doom and in DeHackEd/DECOHack. I wonder if I should make a parameter type in DECOHack that double-checks the appropriate flagging?

 

EDIT: I agree with me - I made an enhancement issue: https://github.com/MTrop/DoomTools/issues/77

 

Edited July 13, 2022 by MTrop : Added DECOHack issue

[s4f3s3x]

Is it possible to have widescreen disabled, or at least a pillarbox option?
I usually like to play in the classic squarish view, but all I have in DSDA is 4:3 aspect ratio stretched