dsda-doom v0.27.5 [2023-12-03]

There also seems to be an issue with the OpenGL renderer as well, trying to switch to it at all makes DSDA-Doom freak out and not respond (though closing the terminal closes it if necessary).

I wonder why some are having problems with opengl. There's no difference in this version compared to the last.

1 minute ago, dsda-dev said:

I wonder why some are having problems with opengl. There's no difference in this version compared to the last.

How much VRAM does it take to use the OpenGL mode?

56 minutes ago, Dweller said:

 

How much VRAM does it take to use the OpenGL mode?

Not nearly enough to cause problems on any hardware from the last 15 or so years.

4 minutes ago, Graf Zahl said:

 

Not nearly enough to cause problems on any hardware from the last 15 or so years.

 

I'd thought it was that since changing to OpenGL made my graphics driver act a little weird (I had to reset brightness/colors each time I tried to use OpenGL), but what could it be if not that?

@dsda-dev I have a problem on MacOs, launching the program with Exclusive Fullscreen disabled makes the cursor appear on the screen losing mouse control in-game, so becomes basically unplayable. Same when starting in windowed mode. Curiously, this doesn't happen if I switch Exclusive from ON to OFF from the in-game menù, i.e. after having already launched DSDA in Fullscreen + Exclusive ON.

This is a problem specifically because some lower resolutions only render correctly with Exclusive Fullscreen disabled - 320x200, 640x400, etc...

You can't click on the window or switch focus to it? What renderer? @PBeGood4 do you have any idea about that?

1 hour ago, dsda-dev said:

You can't click on the window or switch focus to it? What renderer? @PBeGood4 do you have any idea about that?

Yeah, pardon. It's about the Software renderer.

Clicking on the screen / window makes no effect. Switching focus between desktops (the "swipe" you do on a Macbook's trackpad) is briefly effective for some seconds, then loses focus again. Doing it more times seems to have permanent effect, but it's extremely uncomfortable having to launch DSDA, swipe, click, swipe again, lose focus, swipe, clicking, etc... etc...

I found a quick solution by launching the port with the "fullscreen" option in the launcher .app disabled: that makes the game start windowed, then I cmd+F for fullscreen and after that everything is normal (while still having Exclusive Fullscreen disabled, of course).

Glad you found a workaround for now. If you launch the game directly instead of using the launcher, does it have the issue or can you go straight to full screen? Basically, is it related to the launcher or the port itself?

25 minutes ago, dsda-dev said:

Glad you found a workaround for now. If you launch the game directly instead of using the launcher, does it have the issue or can you go straight to full screen? Basically, is it related to the launcher or the port itself?

I now tried to launch the .bin directly with RocketLauncher2 (I don't know how to do it from terminal), the issue presents itself again: goes straight to fullscreen, but doesn'0t grab mouse.

@rfomin re opl3: This is awesome, big thank you to the devs!

I encountered an issue while I was setting up my copy of the latest version available (0.27.2). Whenever I change to opengl, the executable crashes and sends this message:

Could this have to do with counting with outdated drivers? I didn't have any glaring problems with 0.25.6. which is the version I've been using. If there was another version update between 25 and 27, sorry I didn't catch it in time. 

@s4f3s3x This never happened to me in any version (just tried it on 0.27.2) and neither when using the launcher nor the terminal.

When the game is started, it ALWAYS captures the mouse.

If you press ESC to open the menu:

- On fullscreen: mouse is still captured by the game

- On windowed: mouse is released (but it is captured again when exiting the menu)

Can you tell me more about this? Game version, OS version, any other things you think could be impactful

5 hours ago, PBeGood4 said:

@s4f3s3x This never happened to me in any version (just tried it on 0.27.2) and neither when using the launcher nor the terminal.

 

When the game is started, it ALWAYS captures the mouse.

If you press ESC to open the menu:

- On fullscreen: mouse is still captured by the game

- On windowed: mouse is released (but it is captured again when exiting the menu)

 

Can you tell me more about this? Game version, OS version, any other things you think could be impactful

The problem is not with fullscreen per se, rather than the Exclusive Fullscreen option being turned ON or OFF at the start of the program.

As of now, I'm using DSDA v0.27.0 on a MacBook Pro M1 (2021) with macOs Ventura 13.3

Win32 build of dsda-doom 0.27.2

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

I skipped version 0.27.1

Making progress on the opengl investigation, hoping to have a fix in 0.27.3 for anyone affected.

14 hours ago, s4f3s3x said:

 

The problem is not with fullscreen per se, rather than the Exclusive Fullscreen option being turned ON or OFF at the start of the program.

As of now, I'm using DSDA v0.27.0 on a MacBook Pro M1 (2021) with macOs Ventura 13.3

Ive tried messing around with it, and its working correctly on my end. I have no idea what the problem could be.

23 minutes ago, PBeGood4 said:

 

Ive tried messing around with it, and its working correctly on my end. I have no idea what the problem could be.

Do you know if MacOs has some system settings to regulate these things?

58 minutes ago, s4f3s3x said:

 

Do you know if MacOs has some system settings to regulate these things?

No, I don't think that is a thing. :\

There are not so many words in the world to describe how much I love this port!

Stable, minimalistic, up-to-date, compatible.

What more do you need to be completely happy?)

@dsda-dev Are saves from v0.27.0 compatible with v0.27.2?

38 minutes ago, s4f3s3x said:

@dsda-dev Are saves from v0.27.0 compatible with v0.27.2?

Yes, there shouldn't be an issue.

Updated to v0.27.3 (same link in first post)

- Fixed opengl renderer not working for some people

- Fixed duplicate wipe when reloading with use while dead

If you still have issues with opengl let me know. Thanks to ReaperAA and VanBog for debugging the issue with me.

Thank you for this update on the opengl issue, it appears to be all seamless now on my end.

By the way, in the meantime I was checking how the implementation of opl3 feels in Resurgence (it's good), and by pure coincidence I noticed also that performance in software was suspiciously smoother than ever, that I thought for a moment that it was set to opengl. I read a while ago about software mode getting improved in some now older version but didn't quite pay attention to it, until now. I later checked some maps where I would previously experience important performance lag and, to my surprise, there's been a vast improvement that I was apparently ignoring before, such that personal cases like Sunder map 14 or Doomium map 15 run, for the most part, consistently smooth throughout now for me. Another example is D2INO-RDC map 12, where I do get frame drops pretty much all the time, but it's much more workable compared to opengl. That's interesting to find out. Better late than never to say thanks for the software improvement!

Onto a completely different question... is there a reason why the "tags apply locally" mapping-error option is gone? Unless it's been moved to another list in the setup, because I used to use that option for those extremely rare cases of broken tag 0 stuff in '00s maps. 

How do I make use of the hud directory in Linux? I assumed it's where you can put hud cfgs and load them without specifying the full path but I can't get it to work that way.

custom huds can be autoloaded just like any other pwad, you just need to use "DSDAHUD.LMP" as filename

Win32 build of dsda-doom v0.27.3

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

just noticed something weird with the opengl skybox in eviternity

warp to map26 and enable/disable freelook while standing on the starting platform after it has emerged completely

the sky texture will change from the intended pinkish one to a grey one

it doesn't seems to be related to a palette issue, since the cloud formations change as well (leading me to believe an entirely different texture is being used)  

even stranger: if you strafe to the left/right and stop by the railing, then enabling/disabling freelook while standing there will not trigger the "sky swap"

this is using 0.27.3 win64 with a default cfg, empty autoload folders, doom2.wad and complevel 11

17 hours ago, galileo31dos01 said:

Onto a completely different question... is there a reason why the "tags apply locally" mapping-error option is gone? Unless it's been moved to another list in the setup, because I used to use that option for those extremely rare cases of broken tag 0 stuff in '00s maps. 

At some point I had to rewrite how tag searching works (probably when adding udmf's ability to have multiple tags per line / sector) and that feature wasn't migrated. I think it would be better to implement a proper demo-compatible feature for this using a comp flag, but haven't pursued that as I've been focusing on other things.

8 hours ago, liPillON said:

just noticed something weird with the opengl skybox in eviternity

The domed sky mode used when freelook is on isn't perfect. I know one issue happens if there are sectors in view that have different skies (not sure that's the case here).

3 hours ago, dsda-dev said:

The domed sky mode used when freelook is on isn't perfect. I know one issue happens if there are sectors in view that have different skies (not sure that's the case here).

Yeah that is what's going on. It's a problem in PrB+ as well. In fact the Eviternity text file states "NOTE: GLBoom breaks skies but works other than that."