This is Woof! 14.5.0 (Apr 30, 2024)

[Julia Nechaevskaya]

@bofu, famous problem we have suffered across several ports, notably on toggling vertical sync. Are you on Windows 10/11? If so, it's still unclear what was happened: either it comes with one recent Windows updates more than half of year ago, or something went wrong in SDL library itself, or perhaps both cases are mixed somehow. We have fixed it for SDL 2.0.22 by very crazy condition condition.

 

However, new SDL 2.24.0 is out and screen freezing seems to be gone even without that condition. We decided to wait a little bit before port's library update, since MSYS build system still using old 2.0.22 version.

 

Anyways, could you please try to use to use official build of SDL 2.24.0 and see is screen freeze still happening?

[bofu]

8 hours ago, Julia Nechaevskaya said:

@bofu, famous problem we have suffered across several ports, notably on toggling vertical sync. Are you on Windows 10/11? If so, it's still unclear what was happened: either it comes with one recent Windows updates more than half of year ago, or something went wrong in SDL library itself, or perhaps both cases are mixed somehow. We have fixed it for SDL 2.0.22 by very crazy condition condition.

 

However, new SDL 2.24.0 is out and screen freezing seems to be gone even without that condition. We decided to wait a little bit before port's library update, since MSYS build system still using old 2.0.22 version.

 

Anyways, could you please try to use to use official build of SDL 2.24.0 and see is screen freeze still happening?

 

I am indeed using Windows 11. I had compiled using the 2.24.0 VC package. I also went ahead and took the current binary release and copied the 2.24.0 library into the Woof folder over the 2.0.22 DLL that was included, and I was able to reproduce the issue, but it went away once I switched the DLL back to 2.0.22. I guess something in 2.24.0 is breaking things.

 

This also only happens with V-Sync on.

Edited August 25, 2022 by bofu

[Garlichead]

Reporting this here as i am not sure if it a port issue or a wad issue.

 

I found some weird visual glitches on map e1m3 of Solar Struggle.

This should be a solid wall and looks all warpy, i am playing the wad with this options on:

 -save Solar
 -shotdir Solar
 -complevel 3 

The walls look fine on Prboom+  2.6.2

I am using Woof-10.2.0-win64 on windows 10.

 

I also posted this on the Solar Struggle thread on the link below

https://www.doomworld.com/forum/post/2536868

 

Also, please find this save file right next to the offending wall.

woofsav1.zip

Edited August 25, 2022 by Garlichead
Tested it on Prboom+

[PKr]

@Garlichead

 

Interesting... For some odd reason Woof tries to render the backside of the wall. If you flip the sides of the lines in question, Woof will render them properly.

[Garlichead]

11 minutes ago, PKr said:

@Garlichead

 

Interesting... For some odd reason Woof tries to render the backside of the wall. If you flip the sides of the lines in question, Woof will render them properly.

Weird, the bug also happens on the eastern wall from where that lamp is. 

[rfomin]

4 hours ago, Garlichead said:

I found some weird visual glitches on map e1m3 of Solar Struggle.

Thanks for the report. This seems to be a side effect of this fix: https://github.com/fabiangreffrath/woof/pull/565 @fabian I guess we should bring it in line with PrBoom+.

[Garlichead]

18 minutes ago, rfomin said:

Thanks for the report. This seems to be a side effect of this fix: https://github.com/fabiangreffrath/woof/pull/565 @fabian I guess we should bring it in line with PrBoom+.

No problem.

 

Is this the best way to report a bug, or what kind of information can i provide in the future to make it easier for everyone? 

[rfomin]

36 minutes ago, Garlichead said:

Is this the best way to report a bug, or what kind of information can i provide in the future to make it easier for everyone? 

Your report is good - savegame or demo with the problem is the best way.

[heliumlamb]

is it just me or are the left and right channels swapped when using the OPL emulation? a part would play back panned hard right in chocolate, crispy, zdoom 2.8.1 and eternity's OPL3 emulations plays back panned hard left in woof. this discrepancy is not present when switching midi playback to fluidsynth.

[fabian]

16 hours ago, rfomin said:

Thanks for the report. This seems to be a side effect of this fix: https://github.com/fabiangreffrath/woof/pull/565 @fabian I guess we should bring it in line with PrBoom+.

 

Sure! Any idea what's missing? 

 

15 hours ago, Garlichead said:

Is this the best way to report a bug, or what kind of information can i provide in the future to make it easier for everyone? 

 

I prefer the issue tracker on github, but posting here is alright as well, of course. 

 

4 hours ago, heliumlamb said:

is it just me or are the left and right channels swapped when using the OPL emulation? a part would play back panned hard right in chocolate, crispy, zdoom 2.8.1 and eternity's OPL3 emulations plays back panned hard left in woof. this discrepancy is not present when switching midi playback to fluidsynth.

 

Ah, Chocolate et al. emulate a bug in vanilla Doom that had its channels switched in OPL music playback. However, this has become so common, that playback with the correct channel mapping is considered a bug today. I will look into it. 

[heliumlamb]

5 minutes ago, fabian said:

Ah, Chocolate et al. emulate a bug in vanilla Doom that had its channels switched in OPL music playback. However, this has become so common, that playback with the correct channel mapping is considered a bug today. I will look into it. 

thank you! if this info helps, the channels on woof's other midi playback options (windows native and fluidsynth) are consistent with what i would expect, and consistent with what i hear in various recordings from general midi boxes.

i was curious and it seems the channels in woof's opl3 emulation match what i'm getting with vanilla doom under dosbox when DMXOPTION is set to -opl3, which would be using the dmx library with the reversed opl channels. https://doomwiki.org/wiki/DMX#Other_bugs

 

[Brainfreezzzzz]

I'm new to woof so I may be doing something wrong but when I go to either join a server or create my own using woof-setup.exe I get the error message "No such option '@C:\Users\Owners\AppData\Local\Temp\woof.rsp'.", I am not sure exactly what this means but when I run singleplayer woof.exe it works fine, I have the correct Doom2 wad too, so I am unsure.

[xX_Lol6_Xx]

1 hour ago, Brainfreezzzzz said:

I'm new to woof so I may be doing something wrong but when I go to either join a server or create my own using woof-setup.exe I get the error message "No such option '@C:\Users\Owners\AppData\Local\Temp\woof.rsp'.", I am not sure exactly what this means but when I run singleplayer woof.exe it works fine, I have the correct Doom2 wad too, so I am unsure.

For the time being, use batch files with parameter -server and -connect.

I also have this message error, but after compiling from source binaries instead of using the Win exes.

Also, tiny feature request, could it be possible to add a view/weapon bobbing controller like in Crispy Doom? So far there's only a little toggle. 

[fabian]

3 hours ago, Brainfreezzzzz said:

 "No such option '@C:\Users\Owners\AppData\Local\Temp\woof.rsp'.", 

 

This bug was fixed literally one day after the latest release. 

 

1 hour ago, xX_Lol6_Xx said:

Also, tiny feature request, could it be possible to add a view/weapon bobbing controller like in Crispy Doom? So far there's only a little toggle. 

 

Sorry, but which toggle are you missing? We already have one for weapon bobbing and one for weapon attack alignment in the Options->Weapons menu. 

[xX_Lol6_Xx]

2 minutes ago, fabian said:

Sorry, but which toggle are you missing? We already have one for weapon bobbing and one for weapon attack alignment in the Options->Weapons menu. 

Nono, I was asking for a way to control view bobbing as well. Like in Crispy Doom, where you can set view and weapon bob to full, 75% or off instead of just on/off. Maybe I should have been more clear

[fabian]

On 8/26/2022 at 4:18 PM, heliumlamb said:

i was curious and it seems the channels in woof's opl3 emulation match what i'm getting with vanilla doom under dosbox when DMXOPTION is set to -opl3, which would be using the dmx library with the reversed opl channels. https://doomwiki.org/wiki/DMX#Other_bugs

 

Right, Woof! is using OPL3 emulation by default. Just checked the code, stereo reverse emulation is available, but disabled by default. So, everything seems to be working as expected. 

[Gez]

3 hours ago, fabian said:

Right, Woof! is using OPL3 emulation by default. Just checked the code, stereo reverse emulation is available, but disabled by default. So, everything seems to be working as expected. 

If I follow what @heliumlamb says, it seems to actually be enabled by default?

[fabian]

22 hours ago, Gez said:

If I follow what @heliumlamb says, it seems to actually be enabled by default?

 

Woof's OPL3 emulation is supposed to sound exactly like Crispy, or Choco with DMXOPTION="-opl3" which emulate the bug of the stereo channels being switched. This means it will sound switched in turn if compared to any other MIDI playback engine, but this is intended. I had this glitch disabled in Crispy for a while and got a bug report asking to revert it:

https://github.com/fabiangreffrath/crispy-doom/issues/454#issuecomment-618901773

 

TL;DR: In E1M1, the music starts playing in the left speaker.

Edited August 31, 2022 by fabian

[Renbot]

Would you ever consider implementing the "organise my save files" feature from DSDA Doom? Sorry if it has been asked before. It's the feature which automatically separates your save files based on which wads/files you've loaded. This way the save menu screen is clutter free and you only see saves from the specific combination of files you have loaded at time.

 

[DeletedAccount]

 

Thank you @Dwars for making a video on Woof and its other forks.

Edited September 5, 2022 by Heck Yeah

[bofu]

Would it be possible to add the option to change the window size to the menu? In particular, I'd like to be able to define the window_width and window_height without having to edit the cfg file. For the longest time, I simply assumed that I couldn't set the resolution in windowed mode, but now that I see that I can, Woof has basically everything I'm looking for in a source port (just not all necessarily exposed in the UI).

 

If there's somewhere I'm not seeing it, my bad.

[rfomin]

35 minutes ago, bofu said:

Would it be possible to add the option to change the window size to the menu? In particular, I'd like to be able to define the window_width and window_height without having to edit the cfg file.

You can simply resize with the mouse like a regular window.

[liPillON]

seeing that you're prepping up the 10.2.1 release, I'll try sneaking in a minor feature request

 

would it be feasible to render the boom HUD without it being affected by custom playpals/colormaps?

just asking.. ;) 

[andrewj]

On 8/31/2022 at 12:58 AM, fabian said:

or Choco with DMXOPTION="-opl3" which emulate the bug of the stereo channels being switched

I think that merely enables OPL3 mode, it is DMXOPTION="-reverse" which swaps the channels.

[DeletedAccount]

On 8/23/2022 at 12:28 PM, fabian said:

Sorry, wrong source port. 

Yeah lol

[fabian]

On 9/6/2022 at 10:58 AM, Delfino Furioso said:

would it be feasible to render the boom HUD without it being affected by custom playpals/colormaps?

just asking.. ;) 

 

HUD colors are actually saved as palette indices. So, if a PWAD changes the palette, it inevitably changes the HUD colors as well. 

 

If you are asking for something like "with 'red' I mean the same RGB color as index 176 in the original palette", then that'd be a not-so-minor feature request at all. ;)

 

On 9/6/2022 at 1:33 PM, andrewj said:

I think that merely enables OPL3 mode, it is DMXOPTION="-reverse" which swaps the channels.

 

The way I understand it, the channels are already reversed without that option and setting it would reverse them back to their strictly correct (but unfamiliar for Doom players) order. 

[liPillON]

1 hour ago, fabian said:

HUD colors are actually saved as palette indices. So, if a PWAD changes the palette, it inevitably changes the HUD colors as well. 

 

If you are asking for something like "with 'red' I mean the same RGB color as index 176 in the original palette", then that'd be a not-so-minor feature request at all. ;)

 

I see..

So asking for "when rendering hud's red text, use rgb(255,0,0) no matter what" and so on would require a substantial effort.

I guess this would have a true-color renderer as a prerequisite, right?

[DeletedAccount]

Hello Mr. @fabian

 

If I start playing Doom 2 on Woof! with the earlier versions of Doom 2 (i.e versions before 1.9), and change the compatibility setting to Vanilla, will Woof automatically emulate the behaviour of the respective doom 2's earlier versions ?

 

And sir, by the way, what do you think, should Woof! have the compatibilty emulation of Doom 2's versions 1.2,1.666,1.9 just like there is in Prboom plus ?

Edited September 7, 2022 by Heck Yeah

[ReaperAA]

38 minutes ago, Heck Yeah said:

Hello Mr. @fabian.

I downloaded Doom 2 Hell on Earth v1.666, 1.7 and 1.8 from this site 👇: 

 

I would recommend to edit your comment to remove that link since those are illegal/pirated files and piracy is discouraged here.

[DeletedAccount]

12 minutes ago, ReaperAA said:

 

I would recommend to edit your comment to remove that link since those are illegal/pirated files and piracy is discouraged here.

Oh thank you so much..