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

dsda-doom source port [v0.24.3]

Recommended Posts

4 hours ago, kraflab said:

A cursory google indicates you may have a problem with how you're linking things when you compile. Pt_Time is defined in porttime.h, which is correctly included in portmidiplayer.c.

can't find any "porttime.h" in the git repo or in any files i could find on my PC,though maybe im interpreting you wrong,im not very well versed in this stuff.

Share this post


Link to post

The porttime.h file is coming from the porttime library, it's not part of the source port's code. Basically, the linker (/usr/bin/ld) is not able to find the porttime library directly when you try to compile.

Share this post


Link to post
1 hour ago, esspressoman said:

can't find any "porttime.h" in the git repo or in any files i could find on my PC,though maybe im interpreting you wrong,im not very well versed in this stuff.

 

I'm on debian and it compiles fine.  I didn't try compiling on arch, but have an arch machine and am familiar with how things work there; the portmidi package should provide that header

https://archlinux.org/packages/extra/x86_64/portmidi/

dsda-doom is in the AUR and the AUR lists portmidi as an explicit dependency, so I'm not sure why it failed on your setup, but seems you should reach out to the AUR maintainer or the arch forums..

Share this post


Link to post
52 minutes ago, siege cunt said:

 

I'm on debian and it compiles fine.  I didn't try compiling on arch, but have an arch machine and am familiar with how things work there; the portmidi package should provide that header

https://archlinux.org/packages/extra/x86_64/portmidi/

dsda-doom is in the AUR and the AUR lists portmidi as an explicit dependency, so I'm not sure why it failed on your setup, but seems you should reach out to the AUR maintainer or the arch forums..

ok,i'll try to contact him about it,

Share this post


Link to post

I would like to ask if in PrBoom-plus/DSDA-Doom, with the OpenGL render, there was a setting that simulates the lighting system of the render software (a bit like in EDuke32, there is also the palette emulation) in so that I can also use it with the original levels (Ultimate Doom, Doom 2, etc).

 

 

As for the click issue in sound effects, it also happens in Woof! and Crispy Doom, always in the sounds that play quickly and repeat themselves.

Share this post


Link to post
6 minutes ago, Kappa971 said:

I would like to ask if in PrBoom-plus/DSDA-Doom, with the OpenGL render, there was a setting that simulates the lighting system of the render software (a bit like in EDuke32, there is also the palette emulation) in so that I can also use it with the original levels (Ultimate Doom, Doom 2, etc).

I think you have to change the sector light mode to shaders, it's here:

Options -> General -> Page 5 -> Sector light mode, here press enter and change it to shaders, then press F11 until the gamma correction is set to 0 or whatever you like

 

Share this post


Link to post
7 minutes ago, Lol 6 said:

I think you have to change the sector light mode to shaders, it's here:

Options -> General -> Page 5 -> Sector light mode, here press enter and change it to shaders, then press F11 until the gamma correction is set to 0 or whatever you like

OK thanks :)

Share this post


Link to post

Hello, here to report a few things:

 

- Zoom out isn't working, no matter which key I bind it simply won't do anything.

 

- It's been crashing indiscriminately every time I take a screenshot. The message is no other than "Exit on signal 11", just now it's somehow happening all the time regardless of how long I've been playing. The screenshot is saved though.

 

- I've actually had another crash yesterday with the message "Z_Free: freed a pointer without ZONEID", when it was about to load the next map after the intermission screen. Was while playing this recent wad, m07 after m06 if that is of any help.

 

This is all using the latest update, and in OpenGL. 

Share this post


Link to post
25 minutes ago, galileo31dos01 said:

Hello, here to report a few things:

 

- Zoom out isn't working, no matter which key I bind it simply won't do anything.

 

- It's been crashing indiscriminately every time I take a screenshot. The message is no other than "Exit on signal 11", just now it's somehow happening all the time regardless of how long I've been playing. The screenshot is saved though.

 

- I've actually had another crash yesterday with the message "Z_Free: freed a pointer without ZONEID", when it was about to load the next map after the intermission screen. Was while playing this recent wad, m07 after m06 if that is of any help.

 

This is all using the latest update, and in OpenGL. 

Please post your config file (dsda-doom.cfg).

Share this post


Link to post
4 hours ago, kraflab said:

I have no problem zooming out with this config. Can you explain exactly what you're doing? Just pressing the minus key?

 

So... I mistook the zoom in/out keys from the automap with the "larger/smaller view" keys, so there're no problems with any of them... big apologies...

Share this post


Link to post
On 8/17/2021 at 6:07 PM, Bytefyre said:

I think I might've discovered a minor bug related to UMAPINFO.  I'd put together a UMAPINFO file for Eviternity and figured out that by using the "enterpic" field for each map, I could have the map's special graphic (which is of type Graphic (Doom) than a Graphic (Flat)) display as it loaded rather than melting from a black screen.  However, when I watched someone streaming Eviternity finish the game while using my file, after the stats screen for Map 30 disappeared, it briefly showed the graphic for Map 31 before melting to the ending story screen.  Is there something that can be done to not load the next numeric level's enterpic value if the level just completed has one of the endgame fields specified (my Map 30 entry has endcast = true)?

eviternity_um.zip

 

I think I understand what was going on with this better now.  While I do see there was a change to prevent an "entering screen" from being shown for maps that have one of the end tags specified, I think that only covered the "levelpic" field, not the "enterpic" field, and that's where the change needs to be made.

Share this post


Link to post

UMAPINFO behaviour changes / fixes need to go through the prboom+ repo first, then I will merge them from upstream.

Share this post


Link to post

when playing Evilternity with OpenGl and no vertical mouse aiming the sky dropes way down.  It looks fine in software mode or with vertical mouse aim.  I haven't noticed this with other mods.

Spoiler

screenshot_dsda-doom_Eviternity.png.14d262266ac9cffac0f20d33bb38e161.png

 

Share this post


Link to post
Quote

when playing Evilternity with OpenGl and no vertical mouse aiming the sky dropes way down.  It looks fine in software mode or with vertical mouse aim.  I haven't noticed this with other mods.

I believe this problem has been solved after the release of PrBoom-Plus 2.6.1um. Here is the updated 64-bit Windows binary of DSDA-Doom (I also included Widescreen resources for Doom, Doom 2 and Final Doom): dsda-doom_win64.7z

 

My curiosity, I would like to ask why compiling PrBoom-plus/DSDA-Doom with Visual Studio, the number of required .dlls is less (16 .dll files vs 40 .dll files).

Edited by Kappa971

Share this post


Link to post
2 hours ago, Kappa971 said:

I believe this problem has been solved after the release of PrBoom-Plus 2.6.1um. Here is the updated 64-bit Windows binary of DSDA-Doom (I also included Widescreen resources for Doom, Doom 2 and Final Doom): dsda-doom_win64.7z

 

My curiosity, I would like to ask why compiling PrBoom-plus/DSDA-Doom with Visual Studio, the number of required .dlls is less.

I tried the accompanying file and it didn't fix the sky.

Share this post


Link to post
36 minutes ago, Blue Phoenix said:

I tried the accompanying file and it didn't fix the sky.

Spoiler

494826966_BaseProfileScreenshot2021_11.04-20_28_17_68.png.d3b6e22735a5232038f85c9efc855d0c.png

As you can see, the sky is displayed almost correctly, the moon is wider than in the software render but certainly better than before. I recommend you try a "clean install" of DSDA-Doom, with the files I shared.

Share this post


Link to post
23 minutes ago, Kappa971 said:

As you can see, the sky is displayed almost correctly, the moon is wider than in the software render but certainly better than before. I recommend you try a "clean install" of DSDA-Doom, with the files I shared.

 I did do a clean install, but I put in my preferred setting before running evilternity.  This time I changed my setting one at a time and it turns out changing FOV made the sky drop.  I can set mouse look On and mouse pitch to 0 as a workaround.

Share this post


Link to post
3 hours ago, Kappa971 said:

My curiosity, I would like to ask why compiling PrBoom-plus/DSDA-Doom with Visual Studio, the number of required .dlls is less (16 .dll files vs 40 .dll files).

There are many factors that affect this, and two people compiling in the same environment could have different numbers as well. It depends on how many libraries you use (many are optional when compiling) and how you link those libraries.

Share this post


Link to post
1 hour ago, Blue Phoenix said:

This time I changed my setting one at a time and it turns out changing FOV made the sky drop.  I can set mouse look On and mouse pitch to 0 as a workaround.

@kraflab is this a known bug?

Share this post


Link to post
22 minutes ago, Kappa971 said:

@kraflab is this a known bug?

You'll have better luck asking about rendering concerns in the prboom+ thread, since I don't know anything about how it works :^)

It's definitely known that some skies don't work well in some settings.

Share this post


Link to post
2 hours ago, Blue Phoenix said:

 I did do a clean install, but I put in my preferred setting before running evilternity.  This time I changed my setting one at a time and it turns out changing FOV made the sky drop.  I can set mouse look On and mouse pitch to 0 as a workaround.

You can try changing gl_skymode in the config file. The default 0 is "auto" which switches between two of the other values depending on whether you have mouselook turned on. I think it was gl_skymode 3 that gives you the "mouselook on" behavior whether you have mouselook on or off.

 

Also, it turns out the sky issue with FOV changes has been reported on GitHub: https://github.com/coelckers/prboom-plus/issues/385

Share this post


Link to post
4 minutes ago, Shepardus said:

You can try changing gl_skymode in the config file. The default 0 is "auto" which switches between two of the other values depending on whether you have mouselook turned on. I think it was gl_skymode 3 that gives you the "mouselook on" behavior whether you have mouselook on or off.

 

Also, it turns out the sky issue with FOV changes has been reported on GitHub: https://github.com/coelckers/prboom-plus/issues/385

Ey that was my report haha! When playing with a higher FOV i need to set the sky to "skymode 3".

Share this post


Link to post
9 minutes ago, El juancho said:

Ey that was my report haha! When playing with a higher FOV i need to set the sky to "skymode 3".

gl_skymode 3 I don't think it is the right solution as it displays the skies differently than the rendering software. Maybe that issue should be reopened.

Share this post


Link to post
On 11/3/2021 at 3:29 AM, Bytefyre said:

 

I think I understand what was going on with this better now.  While I do see there was a change to prevent an "entering screen" from being shown for maps that have one of the end tags specified, I think that only covered the "levelpic" field, not the "enterpic" field, and that's where the change needs to be made.

While we're on this topic. In GZDoom the enterpic is shown considerably longer before melting instead of only for a second. Why is that? And can that somehow be adapted through umapinfo? The answer is probably no but i'm just curious.

Share this post


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