Jump to content

dsda-doom source port [v0.24.3]


Recommended Posts

Hello!  I think I just found a bug that's actually a part of main PrBoom+ as well as dsda-doom.  Perhaps it's already known, but in software rendering modes other than 8-bit, the borders to each side of the HUD's status bar don't light up when picking up items or when suffering pain.

Share this post


Link to post
7 hours ago, Bytefyre said:

Hello!  I think I just found a bug that's actually a part of main PrBoom+ as well as dsda-doom.  Perhaps it's already known, but in software rendering modes other than 8-bit, the borders to each side of the HUD's status bar don't light up when picking up items or when suffering pain.

You mean, it doesn't work even if "Change palette on pain/bonus" is 'YES'?

Share this post


Link to post
7 hours ago, Bytefyre said:

Hello!  I think I just found a bug that's actually a part of main PrBoom+ as well as dsda-doom.  Perhaps it's already known, but in software rendering modes other than 8-bit, the borders to each side of the HUD's status bar don't light up when picking up items or when suffering pain.

Can confirm, the borders to the side of the HUD (i.e. the parts that are added for widescreen when not stretching the status bar) don't change with the rest of the screen. The status bar itself and the main game area still obey the palette changes. That explains why I wasn't able to reproduce this when you reported it earlier, I was using 8bit.

 

(There are people who use 32bit?)

Edited by Shepardus

Share this post


Link to post

Hi! I'm here just to report that I made a package for dsda-doom for the Arch Linux AUR: https://aur.archlinux.org/packages/dsda-doom/

I'll do my best to keep it updated :)

Please note because there are filename conflicts (the prboom-game-server executable and the manpages), you cannot have both dsda-doom and regular prboom-plus installed

Share this post


Link to post
4 hours ago, Shepardus said:

Can confirm, the borders to the side of the HUD (i.e. the parts that are added for widescreen when not stretching the status bar) don't change with the rest of the screen. The status bar itself and the main game area still obey the palette changes. That explains why I wasn't able to reproduce this when you reported it earlier, I was using 8bit.

 

(There are people who use 32bit?)

Truth be told, I only used 32-bit because I figured it would allow for more colors to come through, but if map/WAD designers are only staying within the 256-color limit anyway, then I'll probably be fine with 8-bit.  Thanks for checking!

Share this post


Link to post
2 hours ago, Bytefyre said:

Truth be told, I only used 32-bit because I figured it would allow for more colors to come through, but if map/WAD designers are only staying within the 256-color limit anyway, then I'll probably be fine with 8-bit.  Thanks for checking!

Contrary to what it sounds like, 32-bit isn't actually a true-color renderer. I'm not clear exactly what it does (as well as 15 and 16-bit), but it's something to do with the colors used in transparency effects.

Share this post


Link to post
1 hour ago, Shepardus said:

Contrary to what it sounds like, 32-bit isn't actually a true-color renderer. I'm not clear exactly what it does (as well as 15 and 16-bit), but it's something to do with the colors used in transparency effects.

Ohhh, I see.  Well, considering I used that DEH patch to turn off transparency for everything except textures, it sounds like 8-bit is definitely the right way to go.  Thanks again for all the info!

Share this post


Link to post

could you add a -reality parameter?

Don't know if you're taking suggestions but a -reality parameter where if you take any damage it instakills you and maybe a -partial reality where only radiation doesnt count towards that

Would make practicing reality runs very fun and easy :D

Share this post


Link to post
8 hours ago, Outrageous Videos said:

could you add a -reality parameter?

Don't know if you're taking suggestions but a -reality parameter where if you take any damage it instakills you and maybe a -partial reality where only radiation doesnt count towards that

Would make practicing reality runs very fun and easy :D

Try this .deh patch: p1hphack.zip  I made it to be able to abuse DSDA-doom's rewind function for TAS videos. Check this madness: https://youtu.be/OMmfsiwBujE Medikits and Stimpacks are unobtainable. Supercharges and Megaspheres only give 1 HP. You'll still have to look out for Berserk packs due to them being required for the powerup. Grab a health bonus to be taken back to 1 HP. You'll also need to time dangerous floors so you don't take floor damage.

Share this post


Link to post
5 hours ago, L0l1nd3r said:

Try this .deh patch: p1hphack.zip  I made it to be able to abuse DSDA-doom's rewind function for TAS videos. Check this madness: https://youtu.be/OMmfsiwBujE Medikits and Stimpacks are unobtainable. Supercharges and Megaspheres only give 1 HP. You'll still have to look out for Berserk packs due to them being required for the powerup. Grab a health bonus to be taken back to 1 HP. You'll also need to time dangerous floors so you don't take floor damage.

This is awesome

Thanks

Share this post


Link to post

reality_dehs.zip

 

Here's a different approach with reality_nocrash.deh that doesn't modify the pickups and always kills the player on the first damage they take (including damaging floors and crushers).

 

Caveats:

- if you happen to be very close to a walk-over exit line when you take damage you might still be able to successfully exit

- if you are very close to a Romero's head when you take damage this approach will actually *help* you exit the map by damaging the head since what it actually does is that it creates an explosion when you take any damage

- doesn't work in Chocolate Doom because it doesn't support the BEX format

 

If you are hardcore and want a foolproof approach use reality_crash.deh - this dehacked intentionally crashes the source port you're using on the first damage you take. Doesn't work (as intended) in ZDoom-based ports or Eternity and hangs Chocolate Doom and Crispy Doom for a while before terminating - you have been warned, use at your own risk!

Edited by Keyboard_Doomer

Share this post


Link to post

I've noticed when recording a demo with -solo-net, the dsda map restart key restarts the map without all the coop things. Maybe it is supposed to work that way, or maybe i'm just doing it wrong. Would be cool if it would restart in coop mode.

 

Enjoying this port, keep up the good work.

Share this post


Link to post
On 5/14/2021 at 2:13 AM, BiZ said:

I've noticed when recording a demo with -solo-net, the dsda map restart key restarts the map without all the coop things. Maybe it is supposed to work that way, or maybe i'm just doing it wrong. Would be cool if it would restart in coop mode.

 

Enjoying this port, keep up the good work.

Fixed for the next release

Share this post


Link to post
On 4/12/2021 at 12:08 PM, antares031 said:

One more minor bug with Heretic on 0.18.0. Empowered dragon claw's hit effect is displayed on the projectile's trails, rather than the hitting point:

This one is fixed for the next release. I never saw it because it only happens with uncapped fps :^)

Share this post


Link to post

I have a very minor bug report.  I was trying out your very nice "have dsda doom organize saves for you" feature (not yet in a release), and I believe you meant to use an octal constant 0733 rather than a hexadecimal constant 0x733 in the call to mkdir on this line:
https://github.com/kraflab/dsda-doom/blob/37788ae3afb6b39582cc02e823a2c7e1215d63ad/prboom2/src/dsda/save.c#L105

I am using Linux, and this affected both the creation of the .dsda-doom/save_files path (which it then couldn't write to and led to a crash of dsda-doom) and the doom2 subdirectory.  I deleted these subdirectories, changed the constant to 0733 in the code, recompiled, and the feature works nicely now.  (Note that without this fix, a crash occurs, since the save_files subdirectory is created without error, but then trying to create the doom2 subdirectory fails.  Perhaps a check would be good there too.)

 

Looking forward to the next release!

 

Also perhaps you should add a document for where to report bugs?  I debated sending a private message, but maybe it's nice to bump the thread and get people interested in this new feature =)

Share this post


Link to post
  • 2 weeks later...

just wanted to bump this thread, since this is the source port giving me the best framerate compared to everything else that's out there. and I've tried it all (gzdoom, prboom+, woof!, eternity, etc.)

really enjoying it!

Share this post


Link to post

hey, why is this not in the "source ports" section? this requires at least its own subforum. anyway, this is a great port. thanks to whoever maintains it!

Share this post


Link to post
11 hours ago, tengv said:

hey, why is this not in the "source ports" section? this requires at least its own subforum. anyway, this is a great port. thanks to whoever maintains it!

Most likely because it is a source port tailored for speedrunners and general demorecorders, so putting it in the speed demos subforum made more sense.  Also, it is kraflab who maintains it :)

Edited by VanaheimRanger

Share this post


Link to post

This is an awesome project, and I'd love to switch to this port. There is only problem is that it's much darker than PrBoom+. In some areas I can't see anything. Is there a setting that I miss? I'm using OpenGL, but it's the same in 32bit.

Share this post


Link to post
40 minutes ago, MatrixCL said:

This is an awesome project, and I'd love to switch to this port. There is only problem is that it's much darker than PrBoom+. In some areas I can't see anything. Is there a setting that I miss? I'm using OpenGL, but it's the same in 32bit.

 

Hi, not sure what operating system are you using but you can solve it by editing dsda-doom.cfg. On linux you have it in ~/.dsda-doom/dsda-doom.cfg (guess it should really be in ~/.config/dsda-doom but many developers ignore this golden rule). There you should have a line:

usegamma                          3

Guess it is 0 by default, insert value that fits you best.

Share this post


Link to post
5 hours ago, VanaheimRanger said:

Most likely because it is a source port tailored for speedrunners and general demorecorders, so putting it in the speed demos subforum made more sense.  Also, it is kraflab who maintains it :)

Makes sense. I was just browsing the source ports forum thinking it contained all the latest source ports but I almost missed DSDA if I hadn't seen it mentioned in some other thread. Also, big props to kraflab. Not only is DSDA the best performing source port (after some tweaks), it also has the best mouse implementation next to gzdoom. I always have some amount of mouse lag with the other ports for some reason but not here.

 

4 hours ago, MatrixCL said:

This is an awesome project, and I'd love to switch to this port. There is only problem is that it's much darker than PrBoom+. In some areas I can't see anything. Is there a setting that I miss? I'm using OpenGL, but it's the same in 32bit.

You can press F11 in-game. I think that's the default key for changing the Gamma setting. I have it set to 2 or something like that. It is definitely darker than other ports.

Share this post


Link to post
7 hours ago, MatrixCL said:

This is an awesome project, and I'd love to switch to this port. There is only problem is that it's much darker than PrBoom+. In some areas I can't see anything. Is there a setting that I miss? I'm using OpenGL, but it's the same in 32bit.

There's an OpenGL subsection in page 5 of general settings containing a sector light mode setting. GLBoom [the default setting] maintains the original 5 gamma levels, while the other 3 have an independent, whopping 33 levels of gamma. They defaulted to something higher than I prefer, so you might have to mash F11 to get to your desired gamma.

Share this post


Link to post

I have a small problem with v0.19, since I always use this launcher to record demos, it works well in v0.18, but now in v0.19 everytime I finished recording a demo, an error will appear. (Normal play without recording won't have this error.)

Spoiler

error.png.0d1b9f52eee90722d0d2af490b0840a5.png

The recorded demos seem fine to play, but the error makes me a bit worried. V0.18 doesn't have this problem, so I wonder if this could be fixed?

Edited by liveincity

Share this post


Link to post

That indicates it can't create a file to store the new splits. Try disabling this feature in the settings - or try using "-data path" for a custom path to put the data folder that stores it. Maybe the launcher is trying to add this into a directory that dsda-doom can't write into.

Share this post


Link to post
1 hour ago, kraflab said:

That indicates it can't create a file to store the new splits. Try disabling this feature in the settings - or try using "-data path" for a custom path to put the data folder that stores it. Maybe the launcher is trying to add this into a directory that dsda-doom can't write into.

I got that error as well. I assume it's "show split data" in the Options -> DSDA-Doom settings session? It seems turning it off doesn't solve the problem.

Share this post


Link to post
Guest
This topic is now closed to further replies.
×
×
  • Create New...