This is Woof! 14.3.0 (Mar 15, 2024)

[Lila Feuer]

So I'm a massive moron, say what you will about old Boom format maps, it's because I forgot to change compatibility to Boom and restart the game. Despite changing compatibility after the fact the savegame preservation kept things on vanilla format, likely resulting in the fuckiness as prescribed. So ignore my previous post.

[BigBoy91]

EDIT: Post redacted due to stupidity and being out of touch with the community.

Edited November 28, 2021 by CleaverHeaver

[lisiczka]

Using Woof for some time really made me appreciate vanilla Doom. Autoload is definitely a killer feature, saves me from so much headache with sideloading music packs, sprites etc for different wads. I also see more and more people choosing Woof over other ports they were using, and everyone note how good Woof feels to play. Really fantastic work.

I have one suggestion which is purely cosmetic. Mark V software renderer (or default quake behavior? idk) has an interesting solution for menu tint. Maybe you guys could pick it and replace those ugly floor tiles with something like this? And maybe add tint to all menus for consistency? Would be nice.

 

240p

Spoiler

 

480p

Spoiler

 

[SiFi270]

Checking out the latest DBP made me discover that having an empty line between [STRINGS] and the string replacements in a DeHackEd lump results in the strings not being replaced. This isn't the case in Crispy Doom or PrBoom family ports.

[rfomin]

19 hours ago, lisiczka said:

I have one suggestion which is purely cosmetic. Mark V software renderer (or default quake behavior? idk) has an interesting solution for menu tint. Maybe you guys could pick it and replace those ugly floor tiles with something like this? And maybe add tint to all menus for consistency? Would be nice.

Interesting suggestion, but these ugly floor tiles have been used in Boom->MBF->PrBoom->PrBoom+ for over 20 years, so I'm not sure if we should remove them. Maybe if we decide to modernize the menu at some point.

 

14 hours ago, SiFi270 said:

Checking out the latest DBP made me discover that having an empty line between [STRINGS] and the string replacements in a DeHackEd lump results in the strings not being replaced. This isn't the case in Crispy Doom or PrBoom family ports.

Thanks for the report, it will be fixed in the next version.

[fabian]

21 hours ago, lisiczka said:

Mark V software renderer (or default quake behavior? idk) has an interesting solution for menu tint. Maybe you guys could pick it and replace those ugly floor tiles with something like this? And maybe add tint to all menus for consistency? Would be nice.

 

This can be achieved by a simple formula, but unfortunately the result looks rather crappy due to our aspect ratio correction (i.e. vertical stretching by factor 1.2):

 

--- a/Source/m_menu.c
+++ b/Source/m_menu.c
@@ -1909,7 +1909,15 @@ void M_DrawBackground(char* patchname, byte *back_dest)
   byte *back_src, *src;
 
   V_MarkRect (0, 0, SCREENWIDTH, SCREENHEIGHT);
+    for (y = 0; y < SCREENHEIGHT<<hires; y++)
+      for (x = 0; x < SCREENWIDTH<<hires; x++)
+      {
+        if ((y & 1) || ((y & 2) && (x & 1)) || (!(y & 2) && ((x + 1) & 1)))
+          *back_dest = 0;
 
+        back_dest++;
+      }
+return;
   src = back_src = 
     W_CacheLumpNum(firstflat+R_FlatNumForName(patchname),PU_CACHE);
 

[liPillON]

ugh.. :)

 

it would be nice though to let users choose which tile/texture should be used for the menu background

 

a while ago I came across a source port that do, but I've forgot its name.. maybe russian doom?

 

[fabian]

No sweat, Woof! will always stay as faithful to Doom/MBF as possible. ;)

Edited December 3, 2021 by fabian

[Lila Feuer]

I must've finished 10+ megawads now easily with Woof! and I will do 10+ more.

[lisiczka]

20 hours ago, fabian said:

This can be achieved by a simple formula, but unfortunately the result looks rather crappy due to our aspect ratio correction (i.e. vertical stretching by factor 1.2)

Damn, that's a shame but thanks for trying anyway.

[Gez]

20 hours ago, Delfino Furioso said:

ugh.. :)

An alternative to that whole mesh overlay idea could be to send the whole background screen through the COLORMAP to darken it by 16 rows. (Or whichever value makes sense after some amount of testing and tweaking.) That would allow the overlayed menu to be guaranteed some contrast without fully hiding the scene.

[lisiczka]

9 hours ago, Gez said:

An alternative to that whole mesh overlay idea could be to send the whole background screen through the COLORMAP to darken it by 16 rows.

This got me thinking that turning the background monochrome would do too, given that all menu elements are brightly colored.

 

But anyway, talking about more practical things, how about negative gamma values? Some 90's wads, like master levels for instance, look extremely dull with even the lowest gamma value. Honestly even IWADS would benefit from -1 gamma.

[fabian]

9 hours ago, Gez said:

An alternative to that whole mesh overlay idea could be to send the whole background screen through the COLORMAP to darken it by 16 rows. (Or whichever value makes sense after some amount of testing and tweaking.) That would allow the overlayed menu to be guaranteed some contrast without fully hiding the scene.

I had this in Crispy for several releases, but have been asked repeatedly to remove it again - for the Vanilla feeling. I am not going to go similar routes with Woof! again. 

[Gez]

1 hour ago, fabian said:

I had this in Crispy for several releases, but have been asked repeatedly to remove it again - for the Vanilla feeling. I am not going to go similar routes with Woof! again. 

Fair enough.

[BigBoy91]

Loving this source port. You've come a long way.

Edited December 5, 2021 by CleaverHeaver

[Alaux]

Hey, I noticed that the "Gamepad" text in the Mouse Sensitivity menu doesn't look for a dedicated graphic lump, unlike "Horizontal" and "Vertical". Related or not, the "Gamepad" string completely vanishes when dedicated graphics are provided for the other two:

Spoiler

Well... now you know.

[rfomin]

6 hours ago, Alaux said:

Hey, I noticed that the "Gamepad" text in the Mouse Sensitivity menu doesn't look for a dedicated graphic lump, unlike "Horizontal" and "Vertical". Related or not, the "Gamepad" string completely vanishes when dedicated graphics are provided for the other two:

Now it is looking for the "M_PADSEN" lump: github

[HackNeyed]

The latest git code crashes with a "Segmentation fault (core dumped)" when I exit Woof. After some testing I think it only crashes when "Show ENDOOM Screen" is enabled. I'm on Ubuntu 20.04.3 LTS and the last working commit that displays ENDOOM (doesn't crash) seems to be fffc6238b088b219b0687198dfc938c328f45190 from the 7th.

[rfomin]

1 hour ago, HackNeyed said:

The latest git code crashes with a "Segmentation fault (core dumped)" when I exit Woof. After some testing I think it only crashes when "Show ENDOOM Screen" is enabled. I'm on Ubuntu 20.04.3 LTS and the last working commit that displays ENDOOM (doesn't crash) seems to be fffc6238b088b219b0687198dfc938c328f45190 from the 7th.

I can't reproduce it on Windows but try this patch:

--- a/Source/i_system.c
+++ b/Source/i_system.c
@@ -347,8 +347,6 @@ void I_Quit (void)
       G_CheckDemoStatus();
    M_SaveDefaults();

-   SDL_QuitSubSystem(SDL_INIT_VIDEO);
-
    SDL_Quit();
 }

 

[HackNeyed]

This is correct, yes?.
 

Quote

 

:~/Build-Doom/woof-master$ patch -p1 < test.patch
patching file Source/i_system.c
:~/Build-Doom/woof-master$ mkdir build && cd build && cmake -DCMAKE_BUILD_TYPE=Release .. && make && cd Source

...

[100%] Built target woof
:~/Build-Doom/woof-master/build/Source$ ./woof

 

 

Still gets me this when I quit...

 

Quote

ST_Init: Init status bar.
Segmentation fault (core dumped)

If I use a brand new config that doesn't exist...

 

Quote

:~/Build-Doom/woof-master/build/Source$ ./woof -config test.cfg

 

It quits fine because ENDOOM is off by default. If I enable ENDOOM in the menu and quit it crashes again without saving any settings.
 

[Gibbon]

I had this problem in ReBOOM on Linux and Mac.  It was because I was not showing the enddoom after the application had successfully exited but instead hijacked the atexit() routine and was chucking it in before it could quit.  Once I refactored that properly, it was fine.  Not sure if it is the same for Woof.  Of course, it doesn't help if the developers only have Windows so they cannot debug this, but it should be easy enough to discover it if putting it through GDB and debugging it.

 

I could do that if it helps?

[rfomin]

6 minutes ago, Gibbon said:

I had this problem in ReBOOM on Linux and Mac.  It was because I was not showing the enddoom after the application had successfully exited but instead hijacked the atexit() routine and was chucking it in before it could quit.  Once I refactored that properly, it was fine.  Not sure if it is the same for Woof.  Of course, it doesn't help if the developers only have Windows so they cannot debug this, but it should be easy enough to discover it if putting it through GDB and debugging it.

 

I could do that if it helps?

ENDOOM worked fine until recently when we integrated net_gui from Chocolate Doom and changed some of the shutdown code. I only have Windows, but Fabian is primarily a Linux developer. Of course, I appreciate the debug session, so yes, please :)

[fabian]

8 hours ago, rfomin said:

changed some of the shutdown code.

 

I can reproduce the segfault on Debian unstable. Though, I guess it's more of a coincidence than a correlation with the introduction of the network code. At about the same time you introduced this code, distributions switched over to SDL 2.0.18 - and I believe this is the culprit here. For some reason, TXT_Init()  fails to create a proper new renderer for the window we pass over to it in TXT_PreInit(). However, I don't even remember anymore why we would destroy the renderer and create a new one instead of just using what we have been pointed to. So, could you please confirm that the following code works for you with SDL 2.0.18?

 

--- a/textscreen/txt_sdl.c
+++ b/textscreen/txt_sdl.c
@@ -265,14 +265,8 @@ int TXT_Init(void)
     if (TXT_SDLWindow == NULL)
         return 0;
 
-    // Destroy the existing renderer, so we can create our own new one
-
-    if (renderer != NULL)
-    {
-        SDL_DestroyRenderer(renderer);
-    }
-
-    renderer = SDL_CreateRenderer(TXT_SDLWindow, -1, SDL_RENDERER_PRESENTVSYNC);
+    if (renderer == NULL)
+        renderer = SDL_CreateRenderer(TXT_SDLWindow, -1, SDL_RENDERER_PRESENTVSYNC);
 
     if (renderer == NULL)
         renderer = SDL_CreateRenderer(TXT_SDLWindow, -1, SDL_RENDERER_SOFTWARE);

 

[HackNeyed]

hmm @fabian I just compiled the txt_renderer branch from git hub and instead of crashing and closing it just hangs. I had fullscreen enabled and had to reboot my machine. Ctrl+C in the terminal didn't close it. killall woof in a separate terminal I could Alt-Tab to didn't close it. I had no mouse pointer to select force quit from the dialog box either. After a reboot I disabled fullscreen and tried again. It still hangs but I can easily force quit the window.

 

EDIT: I'm also on SDL2 2.0.10 it would seem

[fabian]

Are you running a clean out-of-tree build? If unsure, please run "rm -rf build && ./.travis.sh" from the toplevel directory.

[HackNeyed]

28 minutes ago, fabian said:

Are you running a clean out-of-tree build? If unsure, please run "rm -rf build && ./.travis.sh" from the toplevel directory.

 

No idea, I just selected the pull-down menu for branch on the left and downloaded with the green code button on the right. Anyway I extracted it to a new dir and ran this...

 

Spoiler

:~/Build-Doom/woof-txt_renderer-clean$ rm -rf build && ./.travis.sh
Re-run cmake no build system arguments
-- The C compiler identification is GNU 9.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Setting build type to 'RelWithDebInfo' as none was specified.
-- Looking for pow in m
-- Looking for pow in m - found
-- Looking for dirent.h
-- Looking for dirent.h - found
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11")
-- Found SDL2: /usr/include/SDL2 (found suitable version "2.0.10", minimum required is "2.0.7")
-- Found SDL2_image: /usr/include/SDL2 (found version "2.0.5")
-- Found SDL2_mixer: /usr/include/SDL2 (found suitable version "2.0.4", minimum required is "2.0.2")
-- Found SDL2_net: /usr/include/SDL2 (found version "2.0.1")
-- Found Python3: /usr/bin/python3.8 (found version "3.8.10") found components: Interpreter
-- Performing Test CFLAG_Wdeclaration-after-statement
-- Performing Test CFLAG_Wdeclaration-after-statement - Success
-- Performing Test CFLAG_Werror_implicit-function-declaration
-- Performing Test CFLAG_Werror_implicit-function-declaration - Success
-- Performing Test CFLAG_Werror_incompatible-pointer-types
-- Performing Test CFLAG_Werror_incompatible-pointer-types - Success
-- Performing Test CFLAG_Werror_int-conversion
-- Performing Test CFLAG_Werror_int-conversion - Success
-- Performing Test CFLAG_Wformat_2
-- Performing Test CFLAG_Wformat_2 - Success
-- Performing Test CFLAG_Wnull-dereference
-- Performing Test CFLAG_Wnull-dereference - Success
-- Performing Test CFLAG_Wredundant-decls
-- Performing Test CFLAG_Wredundant-decls - Success
-- Performing Test CFLAG_Wrestrict
-- Performing Test CFLAG_Wrestrict - Success
-- Performing Test CFLAG_Wall
-- Performing Test CFLAG_Wall - Success
-- Performing Test CFLAG_Werror
-- Performing Test CFLAG_Werror - Success
-- Configuring done
-- Generating done
-- Build files have been written to: /home/andrew/Build-Doom/woof-txt_renderer-clean/build
...
Run CPack packaging tool...
/usr/bin/cpack --config ./CPackConfig.cmake
CPack: Create package using TGZ
CPack: Install projects
CPack: - Run preinstall target for: Woof
CPack: - Install project: Woof []
CPack: Create package
CPack: - package: /home/andrew/Build-Doom/woof-txt_renderer-clean/build/Woof-8.1.0-Linux.tar.gz generated.

:~/Build-Doom/woof-txt_renderer-clean/build/Source$ ./woof

 

Still hangs.

 

BTW I'm going to be very busy today and maybe the next few days. I'll check in when I can but it may be awhile between any tests or replies. :)

[fabian]

8 hours ago, HackNeyed said:

BTW I'm going to be very busy today and maybe the next few days. I'll check in when I can but it may be awhile between any tests or replies. :)

No problem. If you find the time, it would be very helpful if you could run the game in gdb, hit Ctrl-C when it hangs and provide a backtrace with `bt`.

 

Also, please upgrade to at least SDL 2.0.16. These are bug fix releases and you are literally several years behind. 

[Gibbon]

2 hours ago, fabian said:

No problem. If you find the time, it would be very helpful if you could run the game in gdb, hit Ctrl-C when it hangs and provide a backtrace with `bt`.

 

Also, please upgrade to at least SDL 2.0.16. These are bug fix releases and you are literally several years behind. 

Spoiler

Thread 1 "woof" received signal SIGSEGV, Segmentation fault.
0x00007fffcb284b8f in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
(gdb) bt
#0  0x00007fffcb284b8f in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#1  0x00007fffcacfe08b in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#2  0x00007fffcaba4660 in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#3  0x00007fffcaba6985 in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#4  0x00007fffcaba704e in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#5  0x00007fffcaa838e8 in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#6  0x00007ffff7d89a21 in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#7  0x00007ffff7d7e0b1 in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#8  0x00007ffff7d84c95 in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#9  0x00005555555e817a in TXT_UpdateScreenArea
    (x=x@entry=0, y=<optimized out>, y@entry=0, w=w@entry=80, h=h@entry=25)
    at /home/adam/Downloads/woof-master/textscreen/txt_sdl.c:477
#10 0x00005555555e81e7 in TXT_UpdateScreen ()
    at /home/adam/Downloads/woof-master/textscreen/txt_sdl.c:484
#11 0x00005555555911d9 in I_Endoom
    (endoom_data=0x7ffff2c8ade0 " \016 \017 \017 \017 \017 \017 \017\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@\337@ \017 \017 \017 \017 \017 \017 \017 \017 \017 \017 \017 \017 \017 \017 O O O O O O O O O O O O O"...) at /home/adam/Downloads/woof-master/Source/i_endoom.c:63
#12 0x0000555555594b35 in I_Quit ()
--Type <RET> for more, q to quit, c to continue without paging--c
   _system.c:344
#13 0x00007ffff7aee4e5 in __run_exit_handlers (status=status@entry=0, listp=0x7ffff7cbd818 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:113
#14 0x00007ffff7aee660 in __GI_exit (status=status@entry=0) at exit.c:143
#15 0x0000555555599b17 in M_QuitResponse (ch=121) at /home/adam/Downloads/woof-master/Source/m_menu.c:1239
#16 M_QuitResponse (ch=<optimized out>) at /home/adam/Downloads/woof-master/Source/m_menu.c:1225
#17 0x000055555559d3fd in M_Responder (ev=0x5555556b3488 <events+360>) at /home/adam/Downloads/woof-master/Source/m_menu.c:4781
#18 0x000055555557fb95 in D_ProcessEvents () at /home/adam/Downloads/woof-master/Source/d_main.c:207
#19 0x0000555555582f9c in BuildNewTic () at /home/adam/Downloads/woof-master/Source/d_loop.c:151
#20 0x000055555558310c in NetUpdate () at /home/adam/Downloads/woof-master/Source/d_loop.c:248
#21 0x0000555555583868 in NetUpdate () at /home/adam/Downloads/woof-master/Source/d_loop.c:216
#22 TryRunTics () at /home/adam/Downloads/woof-master/Source/d_loop.c:709
#23 0x00005555555827ea in D_DoomMain () at /home/adam/Downloads/woof-master/Source/d_main.c:2373
#24 0x00005555555779bb in main (argc=<optimized out>, argv=<optimized out>) at /home/adam/Downloads/woof-master/Source/i_main.c:65

 

Ubuntu 21.10, fully updated.

[fabian]

Thanks, but that's a backtrace from the master branch, right? I am sure I fixed that, so I was asking for a backtrace from the txt_renderer branch. 

[Gibbon]

It is from master yes, but it is still broken there.  I'll do another from txt_renderer branch.

 

EDIT: txt_renderer branch works perfectly!  No issues in GDB at all.