This is Woof! 14.3.0 (Mar 15, 2024)

[fabian]

Thanks, that's what I wanted to read! Consider the master branch fixed as well by now. 

[HackNeyed]

5 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. 

 

Yeah it makes sense an LTS will encounter issues with bleeding edge software. I'm probably just out of luck until I upgrade enough packages. Now, I don't know if I've done anything correctly but here are my findings anyway. :)

 

Stumbling half blind skimming tutorials I did...

Quote

$ gdb woof
(gdb) run woof
^C--Type <RET> for more, q to quit, c to continue without paging--c <--- pressing "c"

 

The txt_renderer branch backtrace...

Spoiler

Thread 1 "woof" received signal SIGINT, Interrupt.
syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
38      ../sysdeps/unix/sysv/linux/x86_64/syscall.S: No such file or directory.
(gdb) bt
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007fffc9d58a24 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#2  0x00007fffca68dbf5 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#3  0x00007fffca67587a in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4  0x00007fffc9d52c5d in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5  0x00007fffe0378e27 in glPrimitiveBoundingBox () at /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#6  0x00007fffe036b965 in  () at /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#7  0x00007ffff7dc4307 in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#8  0x00005555555e5d1a in TXT_UpdateScreenArea (x=x@entry=0, y=<optimised out>,
    y@entry=0, w=w@entry=80, h=h@entry=25)
    at /home/andrew/Build-Doom/woof-txt_renderer-clean/textscreen/txt_sdl.c:471
#9  0x00005555555e5d97 in TXT_UpdateScreen ()
    at /home/andrew/Build-Doom/woof-txt_renderer-clean/textscreen/txt_sdl.c:478
#10 0x0000555555590c94 in I_Endoom
    (endoom_data=0x7ffff29981a0 " \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/andrew/Build-Doom/woof-txt_renderer-clean/Source/i_endoom.c:63
#11 0x0000555555593e0f in I_EndDoom ()
    at /home/andrew/Build-Doom/woof-txt_renderer-clean/Source/i_system.c:434
#12 0x0000555555594274 in I_EndDoom ()
    at /home/andrew/Build-Doom/woof-txt_renderer-clean/Source/i_system.c:421
#13 I_Quit () at /home/andrew/Build-Doom/woof-txt_renderer-clean/Source/i_system.c:344
#14 0x00007ffff7aeba27 in __run_exit_handlers
    (status=status@entry=0, listp=0x7ffff7c8d718 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108
#15 0x00007ffff7aebbe0 in __GI_exit (status=status@entry=0) at exit.c:139
#16 0x0000555555599b27 in M_QuitResponse (ch=121)
    at /home/andrew/Build-Doom/woof-txt_renderer-clean/Source/m_menu.c:1239
#17 M_QuitResponse (ch=<optimised out>)
    at /home/andrew/Build-Doom/woof-txt_renderer-clean/Source/m_menu.c:1225
#18 0x000055555559ccbb in M_Responder (ev=0x55555572abe0 <events+480>)
    at /home/andrew/Build-Doom/woof-txt_renderer-clean/Source/m_menu.c:4781
#19 0x000055555557f685 in D_ProcessEvents ()
    at /home/andrew/Build-Doom/woof-txt_renderer-clean/Source/d_main.c:206
#20 0x0000555555582a7c in BuildNewTic ()
    at /home/andrew/Build-Doom/woof-txt_renderer-clean/Source/d_loop.c:151
#21 0x0000555555582bec in NetUpdate ()
    at /home/andrew/Build-Doom/woof-txt_renderer-clean/Source/d_loop.c:248
#22 0x000055555558325c in NetUpdate ()
    at /home/andrew/Build-Doom/woof-txt_renderer-clean/Source/d_loop.c:757
#23 TryRunTics () at /home/andrew/Build-Doom/woof-txt_renderer-clean/Source/d_loop.c:757
#24 0x0000555555582332 in D_DoomMain ()
    at /home/andrew/Build-Doom/woof-txt_renderer-clean/Source/d_main.c:2357
#25 0x00005555555779ab in main (argc=<optimised out>, argv=<optimised out>)
    at /home/andrew/Build-Doom/woof-txt_renderer-clean/Source/i_main.c:65

 

 

The main branch from commit bd071429d9d308bbaa5d00e57f2b53cf3553b08b that "fixed it" backtrace... (it is shorter lol)

Spoiler

Thread 1 "woof" received signal SIGINT, Interrupt.
syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
38      ../sysdeps/unix/sysv/linux/x86_64/syscall.S: No such file or directory.
(gdb) bt
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007fffc9d58a24 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#2  0x00007fffca68dbf5 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#3  0x00007fffca67587a in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4  0x00007fffc9d52c5d in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5  0x00007fffe03d7e27 in glPrimitiveBoundingBox () at /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#6  0x00007fffe03ca965 in  () at /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#7  0x00007ffff7dc4307 in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#8  0x000055555560d657 in TXT_UpdateScreen ()
#9  0x00005555555964ac in I_Endoom ()
#10 0x000055555559ab10 in I_Quit ()
#11 0x00007ffff7aeba27 in __run_exit_handlers
    (status=0, listp=0x7ffff7c8d718 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108
#12 0x00007ffff7aebbe0 in __GI_exit (status=<optimised out>) at exit.c:139
#13 0x00005555555a19e7 in M_QuitResponse ()
#14 0x00005555555a5e09 in M_Responder ()
#15 0x0000555555581cc3 in D_ProcessEvents ()
#16 0x00005555555857ec in BuildNewTic ()
#17 0x0000555555585974 in NetUpdate.part.0 ()
#18 0x0000555555581f84 in D_Display.part.0 ()
#19 0x000055555558507d in D_DoomMain ()
#20 0x000055555557798b in main ()

 

Finally I took the plunge and compiled the resent SDL2 2.0.18 before trying to compile Woof again. The compiler seems to have found it and gdb seems to say Woof is using it in the bt.

 

Quote

-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11")
-- Found SDL2: /usr/local/include/SDL2 (found suitable version "2.0.18", 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")

 

Spoiler

Thread 1 "woof" received signal SIGINT, Interrupt.
syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
38      ../sysdeps/unix/sysv/linux/x86_64/syscall.S: No such file or directory.
(gdb) bt
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007fffc9d58a24 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#2  0x00007fffca68dbf5 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#3  0x00007fffca67587a in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4  0x00007fffc9d52c5d in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5  0x00007fffe038ee27 in glPrimitiveBoundingBox () at /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#6  0x00007fffe0381965 in  () at /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#7  0x00007ffff7d93ee7 in  () at /usr/local/lib/libSDL2-2.0.so.0
#8  0x000055555560d667 in TXT_UpdateScreen ()
#9  0x00005555555964ac in I_Endoom ()
#10 0x000055555559ab10 in I_Quit ()
#11 0x00007ffff7a62a27 in __run_exit_handlers
   (status=0, listp=0x7ffff7c04718 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@en
#12 0x00007ffff7a62be0 in __GI_exit (status=<optimised out>) at exit.c:139
#13 0x00005555555a19e7 in M_QuitResponse ()
#14 0x00005555555a5e09 in M_Responder ()
#15 0x0000555555581cc3 in D_ProcessEvents ()
#16 0x00005555555857ec in BuildNewTic ()
#17 0x0000555555585974 in NetUpdate.part.0 ()
#18 0x00005555555867a5 in TryRunTics ()
#19 0x0000555555585052 in D_DoomMain ()
#20 0x000055555557798b in main ()

 

Same as previous isn't it? I did check "#7  0x00007ffff7d93ee7 in  () at /usr/local/lib/libSDL2-2.0.so.0" <----- This is a symlink that points to /usr/local/lib/libSDL2-2.0.so.0.18.0 so I guess it is using my compiled SDL2 at least. It sounds like you were able to fix it with @Gibbon for updated Linux systems so I'm glad for that. I'll just wait until I upgrade my system for Woof's cool ENDOOM support.

 

BTW thank you, and everyone who codes and mods for all the ports and mods. :)

[fabian]

That last backtrace looks suspiciously similar to the one in https://github.com/coelckers/prboom-plus/issues/191 .

Sigh, I guess at this point it has become clear that we need a custom atexit() sequence.

 

@HackNeyed Please don't upgrade anything, yet. We need the broken state of your system to test the implementation. ;-)

 

[HackNeyed]

@fabian For what it's worth my old and broken system displays the latest PrBoom-PlusUM (and Sprinkled-Doom and ReBoom) ENDOOM screen just fine and without issue.

 

EDIT: Sorry I realized I wasn't using the debug target while building Woof for the last few tests. Should I make a debug build of SDL2 too or is the issue elsewhere? Well, it probably doesn't matter but here is a backtrace from Woof with debug using SDL2 "2.0.16" that I compiled for testing ReBoom because .18 was breaking ReBoom's compile for me. I've PM'd Gibbon about that anyway.
 

Spoiler

Thread 1 "woof" received signal SIGINT, Interrupt.
--Type <RET> for more, q to quit, c to continue without paging--c
syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
38      ../sysdeps/unix/sysv/linux/x86_64/syscall.S: No such file or directory.
(gdb) bt
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x00007fffc9d58a24 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#2  0x00007fffca68dbf5 in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#3  0x00007fffca67587a in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4  0x00007fffc9d52c5d in  () at /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5  0x00007fffe0371e27 in glPrimitiveBoundingBox () at /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#6  0x00007fffe0364965 in  () at /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#7  0x00007ffff7d966c7 in  () at /usr/local/lib/libSDL2-2.0.so.0
#8  0x000055555560cf13 in TXT_UpdateScreenArea (x=0, y=0, w=80, h=25) at /home/andrew/Build-Doom/woof-master/textscreen/txt_sdl.c:477
#9  0x000055555560cf57 in TXT_UpdateScreen () at /home/andrew/Build-Doom/woof-master/textscreen/txt_sdl.c:484
#10 0x00005555555980c8 in I_Endoom
   (endoom_data=0x7ffff2d28fe0 " \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/andrew/Build-Doom/woof-master/Source/i_endoom.c:67
#11 0x000055555559d06b in I_EndDoom () at /home/andrew/Build-Doom/woof-master/Source/i_system.c:438
#12 0x000055555559ce7a in I_Quit () at /home/andrew/Build-Doom/woof-master/Source/i_system.c:346
#13 0x00007ffff7a72a27 in __run_exit_handlers (status=0, listp=0x7ffff7c14718 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108
#14 0x00007ffff7a72be0 in __GI_exit (status=<optimised out>) at exit.c:139
#15 0x00005555555a3c34 in M_QuitResponse (ch=121) at /home/andrew/Build-Doom/woof-master/Source/m_menu.c:1239
#16 0x00005555555a7fee in M_Responder (ev=0x555555756098 <events+440>) at /home/andrew/Build-Doom/woof-master/Source/m_menu.c:4781
#17 0x0000555555581957 in D_ProcessEvents () at /home/andrew/Build-Doom/woof-master/Source/d_main.c:207
#18 0x0000555555585ffc in BuildNewTic () at /home/andrew/Build-Doom/woof-master/Source/d_loop.c:151
#19 0x0000555555586202 in NetUpdate () at /home/andrew/Build-Doom/woof-master/Source/d_loop.c:248
#20 0x0000555555581da7 in D_Display () at /home/andrew/Build-Doom/woof-master/Source/d_main.c:339
#21 0x0000555555585f45 in D_DoomMain () at /home/andrew/Build-Doom/woof-master/Source/d_main.c:2379
#22 0x0000555555598c2b in main (argc=2, argv=0x7fffffffdf08) at /home/andrew/Build-Doom/woof-master/Source/i_main.c:65
(gdb)

 

Edited December 11, 2021 by HackNeyed

[Alaux]

Automap mark numbers beyond a single digit seem to be flawed:

Spoiler

Numbers are 0 through 20, ordered from top to bottom

It seems like the game is trying to put together double digit numbers in the example, but doesn't offset them correctly; you can notice they simply overlap each other.

[HackNeyed]

Hey @fabian I managed to leave some VirtualBox VMs installing overnight. One is Ubuntu-Mate 20.04.3 LTS, the same as my current system and the other is Ubuntu-Mate 21.10 like @Gibbon is running. For both VM I've run their updates and then downloaded Woof master and PrBoom-Plus-UM master to use the dependency install list. I installed cmake and compiled PrBoom-Plus and Woof for testing in both VM. Sorry if this is excessive.

"Dependency install"
 

Spoiler

sudo apt-get install libsdl2-dev libsdl2-net-dev libsdl2-image-dev \
         libpcre3-dev libsdl2-mixer-dev libfluidsynth-dev \
         libportmidi-dev libmad0-dev libdumb1-dev libvorbis-dev libasound2-dev

In Ubuntu 20.04.3 after enabling ENDOOM in Woof it worked! But when I closed the ENDOOM window my terminal said there was a Seg Fault. I ran Woof again and it had saved my settings so I turned off ENDOOM and exited only for it to hang and Seg Fault again! Odd. I tried a few more times and it seems in the VM Woof hangs when ENDOOM is disabled and won't save settings or with ENDOOM enabled it crashes AFTER displaying the ENDOOM screen and saving my settings. It's almost the opposite of my hardware install which only hangs before saving my settings and displaying ENDOOM. Hmm, I'm beginning to regret not replying to that old gypsy woman's emails! ;)

Here are some backtraces

--- With ENDOOM off, freeze and Seg Fault.

Spoiler

Thread 1 "woof" received signal SIGSEGV, Segmentation fault.
0x00007fffca6318bd in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
(gdb) bt
#0  0x00007fffca6318bd in  () at /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#1  0x00007fffca6318ca in  () at /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#2  0x00007fffca98f48c in  () at /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#3  0x00007fffca72204d in  () at /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#4  0x00007fffca69fe97 in  () at /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#5  0x00007fffca62be32 in  () at /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#6  0x00007fffcabf54b7 in  () at /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#7  0x00007fffd0289533 in  () at /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#8  0x00007fffd028c2f9 in  () at /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#9  0x00007ffff7dd1331 in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#10 0x00007ffff7d499cf in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#11 0x000055555559f80d in I_QuitVideo (phase=1) at /home/andrew/Downloads/woof-master/Source/i_video.c:1593
#12 0x000055555559ce98 in I_Quit () at /home/andrew/Downloads/woof-master/Source/i_system.c:352
#13 0x00007ffff7af8a27 in __run_exit_handlers
    (status=0, listp=0x7ffff7c9a718 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true)
    at exit.c:108
#14 0x00007ffff7af8be0 in __GI_exit (status=<optimised out>) at exit.c:139
#15 0x00005555555a3c34 in M_QuitResponse (ch=121) at /home/andrew/Downloads/woof-master/Source/m_menu.c:1239
#16 0x00005555555a7fee in M_Responder (ev=0x555555755ff8 <events+280>) at /home/andrew/Downloads/woof-master/Source/m_menu.c:4781
#17 0x0000555555581957 in D_ProcessEvents () at /home/andrew/Downloads/woof-master/Source/d_main.c:207
#18 0x0000555555585ffc in BuildNewTic () at /home/andrew/Downloads/woof-master/Source/d_loop.c:151
#19 0x0000555555586202 in NetUpdate () at /home/andrew/Downloads/woof-master/Source/d_loop.c:248
#20 0x0000555555586abc in TryRunTics () at /home/andrew/Downloads/woof-master/Source/d_loop.c:709
#21 0x0000555555585f0d in D_DoomMain () at /home/andrew/Downloads/woof-master/Source/d_main.c:2373
#22 0x0000555555598c2b in main (argc=2, argv=0x7fffffffe038) at /home/andrew/Downloads/woof-master/Source/i_main.c:65
(gdb)

 

---With ENDOOM on and displayed. I click in the window to close it then run bt. Its almost identical to the previous bt but there are only 5 lines with "swrast_dri.so" this time?

Spoiler

Thread 1 "woof" received signal SIGSEGV, Segmentation fault.
0x00007fffca631c2a in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
(gdb) bt
#0  0x00007fffca631c2a in  () at /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#1  0x00007fffca98f48c in  () at /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#2  0x00007fffca72204d in  () at /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#3  0x00007fffca69fe97 in  () at /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#4  0x00007fffca62be32 in  () at /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#5  0x00007fffcabf54b7 in  () at /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so
#6  0x00007fffd0289533 in  () at /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#7  0x00007fffd028c2f9 in  () at /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#8  0x00007ffff7dd1331 in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#9  0x00007ffff7d499cf in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#10 0x000055555559f80d in I_QuitVideo (phase=1) at /home/andrew/Downloads/woof-master/Source/i_video.c:1593
#11 0x000055555559ce98 in I_Quit () at /home/andrew/Downloads/woof-master/Source/i_system.c:352
#12 0x00007ffff7af8a27 in __run_exit_handlers
    (status=0, listp=0x7ffff7c9a718 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true)
    at exit.c:108
#13 0x00007ffff7af8be0 in __GI_exit (status=<optimised out>) at exit.c:139
#14 0x00005555555a3c34 in M_QuitResponse (ch=121) at /home/andrew/Downloads/woof-master/Source/m_menu.c:1239
#15 0x00005555555a7fee in M_Responder (ev=0x555555756098 <events+440>) at /home/andrew/Downloads/woof-master/Source/m_menu.c:4781
#16 0x0000555555581957 in D_ProcessEvents () at /home/andrew/Downloads/woof-master/Source/d_main.c:207
#17 0x0000555555585ffc in BuildNewTic () at /home/andrew/Downloads/woof-master/Source/d_loop.c:151
#18 0x0000555555586202 in NetUpdate () at /home/andrew/Downloads/woof-master/Source/d_loop.c:248
#19 0x0000555555586abc in TryRunTics () at /home/andrew/Downloads/woof-master/Source/d_loop.c:709
#20 0x0000555555585f0d in D_DoomMain () at /home/andrew/Downloads/woof-master/Source/d_main.c:2373
#21 0x0000555555598c2b in main (argc=2, argv=0x7fffffffe038) at /home/andrew/Downloads/woof-master/Source/i_main.c:65
(gdb)

 

---With ENDOOM on and displayed but I press crtl+c to run bt before closing the ENDOOM window.

Spoiler

^C
Thread 1 "woof" received signal SIGINT, Interrupt.
0x00007ffff7b8f3bf in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7fffffffdc10, rem=0x7fffffffdc00)
    at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
78    ../sysdeps/unix/sysv/linux/clock_nanosleep.c: No such file or directory.
(gdb) bt
#0  0x00007ffff7b8f3bf in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7fffffffdc10, rem=0x7fffffffdc00)
    at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
#1  0x00007ffff7b95047 in __GI___nanosleep (requested_time=<optimised out>, remaining=<optimised out>) at nanosleep.c:27
#2  0x00007ffff7de51ab in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#3  0x00007ffff7d306e9 in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#4  0x000055555560d808 in TXT_Sleep (timeout=0) at /home/andrew/Downloads/woof-master/textscreen/txt_sdl.c:892
#5  0x00005555555980db in I_Endoom
    (endoom_data=0x7ffff22b8400 " \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@\337@\337@ \017 \017 \017 \017 \017 \017 \017 \017 \017 \017 \017 \017 O ODOOOOOMO:N OKKnKeKeK-KDK"...) at /home/andrew/Downloads/woof-master/Source/i_endoom.c:74
#6  0x000055555559d06b in I_EndDoom () at /home/andrew/Downloads/woof-master/Source/i_system.c:438
#7  0x000055555559ce7a in I_Quit () at /home/andrew/Downloads/woof-master/Source/i_system.c:346
#8  0x00007ffff7af8a27 in __run_exit_handlers
    (status=0, listp=0x7ffff7c9a718 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true)
    at exit.c:108
#9  0x00007ffff7af8be0 in __GI_exit (status=<optimised out>) at exit.c:139
#10 0x00005555555a3c34 in M_QuitResponse (ch=121) at /home/andrew/Downloads/woof-master/Source/m_menu.c:1239
#11 0x00005555555a7fee in M_Responder (ev=0x555555756098 <events+440>) at /home/andrew/Downloads/woof-master/Source/m_menu.c:4781
#12 0x0000555555581957 in D_ProcessEvents () at /home/andrew/Downloads/woof-master/Source/d_main.c:207
#13 0x0000555555585ffc in BuildNewTic () at /home/andrew/Downloads/woof-master/Source/d_loop.c:151
#14 0x0000555555586202 in NetUpdate () at /home/andrew/Downloads/woof-master/Source/d_loop.c:248
#15 0x0000555555586abc in TryRunTics () at /home/andrew/Downloads/woof-master/Source/d_loop.c:709
#16 0x0000555555585f0d in D_DoomMain () at /home/andrew/Downloads/woof-master/Source/d_main.c:2373
#17 0x0000555555598c2b in main (argc=2, argv=0x7fffffffe038) at /home/andrew/Downloads/woof-master/Source/i_main.c:65
(gdb)

 

I hope something here helps.

 

Finally, I did all the same steps as above but in an Ubuntu 21.10 VM and there were absolutely no issues with Woof or it's ENDOOM as already tested and verified. So maybe it's not the old gypsy woman after all. :D

[rfomin]

On 12/11/2021 at 12:58 PM, Alaux said:

Automap mark numbers beyond a single digit seem to be flawed:

  Reveal hidden contents

Numbers are 0 through 20, ordered from top to bottom

It seems like the game is trying to put together double digit numbers in the example, but doesn't offset them correctly; you can notice they simply overlap each other.

Thanks for the report, fixed in github.com

[fabian]

On 12/12/2021 at 2:25 AM, HackNeyed said:

I hope something here helps.

 

 Could you please check if the "atexit" branch fixes the issue for you?

[HackNeyed]

32 minutes ago, fabian said:

 Could you please check if the "atexit" branch fixes the issue for you?

 

Spoiler

...
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
...
--Type <RET> for more, q to quit, c to continue without paging--c  <--- this line is missing in the VM and I don't have to press "c".
[Inferior 1 (process 43298 exited normally]
(gdb) bt
No stack.

 

:D

 

I can confirm it is working with and without ENDOOM in both real and VM Ubuntu-Mate 20.04.3. Also works outside of gdb I just wanted to show the output. :)

 

Thanks. You rock!

[HackNeyed]

So I was playing around in the atexit build wanting to check out the new carry fractional tic and -shorttics behavior. So far it is working great! Thank you. No more skipping inputs while recording and -shorttics works just as it should.

 

However, if you, say, "accidentally" enable the -longtics command while recording at complevel 9 or 11 even though Boom/MBF does not support -longtics. You know, just to "see what happens" then, interestingly the carry fractional tic behavior is disabled and it skips inputs. Sorry! I hope I'm not being annoying as this is clearly a user "error" so I don't know if you want to account for it by ignoring -longtics while recording Boom/MBF like PrBoom+ seems to do or not. To be clear I'm not asking for anything to be done I just thought I'd bring it to your attention. :)

[Doomgirl96]

I've noticed a glitch with this port in Doom 2 in Tricks and Traps and in all subsequent levels that have “The Dave D. Taylor Blues” as the music. Basically the music plays just fine until the either the very end or one of the latter verses where it seems to become permanently stuck on the last note, almost as if someone is holding their finger on the keyboard. Not sure if this is the best way to describe it, might just be me but just putting it out there in case fabian has a fix for this issue. The glitch occurs every time I play the level with either OPL or SDL set as the midi device. 

Edited December 21, 2021 by Doomgirl96

[randomgamerguy1997]

Does the REKKR IWAD not have music? I decided to finally try REKKR and one thing that stood out is the lack of MUSIC. I installed woof-git from the Arch user repository

[HackNeyed]

14 hours ago, Doomgirl96 said:

I've noticed a glitch with this port ... “The Dave D. Taylor Blues” as the music ... it seems to become permanently stuck on the last note

 

Is it "permanently" like for more then 10 seconds or just a couple extra seconds because the later actually happens for me in Doom2.exe in DosBox-X as well as other ports like PrBoom-PlusUM and Sprinkled/Crispy in SDL and OPL. It isn't in hardware recordings I find on YouTube though. Odd.

[Doomgirl96]

Sometimes the note gets stuck around the penultimate verse for about 10 seconds but all the other notes still play on top of it and then it stops. Other times it gets stuck on that note permanently at the very end, it never stops and never loops back to the beginning of the song. It’s just that note and nothing else forever and the only way to stop it is to quit or warp to another level. 

[mikeday]

You are encountering the issue described here: https://doomwiki.org/wiki/Doom_II_music#Trivia

 

According to the GitHub PRs, it looks like rfomin is already working on the fix.

[Doomgirl96]

39 minutes ago, mikeday said:

You are encountering the issue described here: https://doomwiki.org/wiki/Doom_II_music#Trivia

 

According to the GitHub PRs, it looks like rfomin is already working on the fix.

Oh ok, good to know this isn’t an issue solely with this port and that a fix is in the pipeline! 

Edited December 21, 2021 by Doomgirl96

[act]

Pardon my language, but holy fuck is this source port some top-tier stuff. It's officially dethroned PrBoom+ as my port of choice. It runs incredibly fast, while maintaining all the quality of life stuff that's been added to the Doom engine. Shoutout to Dwars for making a video on this port, which inspired me to go out and compile it.

[Lila Feuer]

That D2 MAP08 music looping at the end seems to specifically occur with MAP08 and not MAP22 in my experience, I got around it personally by changing music to MAP22's if stock music is available. I've had it happen in Doom95 and most other source ports, just one of those funny little quirks about the game I thought.

[Alaux]

This is something very specific, but when the Screen Size is 8, the Automap overlay is enabled and the Time/STS display is enabled, the map title is not shown, even though there clearly is room for it:

Spoiler

 

[rfomin]

On 12/21/2021 at 3:46 AM, Doomgirl96 said:

I've noticed a glitch with this port in Doom 2 in Tricks and Traps and in all subsequent levels that have “The Dave D. Taylor Blues” as the music.

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

 

9 hours ago, Alaux said:

This is something very specific, but when the Screen Size is 8, the Automap overlay is enabled and the Time/STS display is enabled, the map title is not shown, even though there clearly is room for it

Yes, it looks like an oversight. I will fix it.

[liPillON]

hi everyone, merry xmas..

 

here I am, looking for a Christmas present: would a crosshair be in line with this port's mission statement? has it ever been considered for inclusion?

 

 

[fabian]

On 12/25/2021 at 1:46 PM, Delfino Furioso said:

would a crosshair be in line with this port's mission statement? has it ever been considered for inclusion?

 

It was considered some time ago, but without a result. I think we couldn't agree upon using the internal HUD font's '+' character as the crosshair. I liked it but didn't care enough and @rfomin didn't like it so we ended up not implementing it at all. ;)

[Bytefyre]

Hello!  I have what I hope will be a quick question.  Is there any way to get the pixel scaling to actually match my fullscreen resolution (1920x1080)?  Right now, regardless of values I put in for window_width, window_height, fullscreen_width, and fullscreen_height in the woof.cfg file, the scaling still seems to be at 852x480, making things farther away more pixelated.

[fabian]

This is the maximum framebuffer resolution for your screen's aspect ratio. Everything else gets upscaled. 

[Bytefyre]

2 hours ago, fabian said:

This is the maximum framebuffer resolution for your screen's aspect ratio. Everything else gets upscaled. 

And there's no way to adjust that in the cfg file?  Is it something I would have to adjust in my Windows system settings, if that's even possible?

 

EDIT:  I'm curious about this because I like the idea of having hardware acceleration that renders using the same sort of color shading as in classic software rendering, while also having the same pixel scaling methodology that DSDA-Doom uses, as its rendering is much sharper if I designate it to use my fullscreen resolution.

Edited December 29, 2021 by Bytefyre

[fabian]

No chance, sorry. 

[PsychEyeball]

Is there ever plans to have some sort of mouselook for this port? PrBoom+ and DSDA-Doom have an interesting compromise on mouselook that I like, where you are able to look everywhere without affecting the vertical angle of your shots (ie. you're looking up toward an enemy and shoot, but if you're not in the right spot for autoaim to trigger, the shot will not travel upwards at all).

 

Having played so many shooters over the years have made it impossible not to rely on mouselook at all, it makes me feel my marine just has a broken neck. Yet, I know that mouselook affecting your aim freely can sometimes break the game and make it easier. Which is why I enjoy the way these two other ports do it, where you do get the commodity without the unfair advantage. 

[Doomgirl96]

What exact changes do the blood colour patches make to Rekkr? I’ve played it both with and without the patch in my autoload folder and haven’t noticed a difference so far. Also does the patch still work for Sunken Land or has it not been tested in that version yet? I’m hesitant to start my rekkr sl playthrough with the blood colour patch in case it causes issues.

[rfomin]

6 hours ago, Doomgirl96 said:

What exact changes do the blood colour patches make to Rekkr? I’ve played it both with and without the patch in my autoload folder and haven’t noticed a difference so far. Also does the patch still work for Sunken Land or has it not been tested in that version yet? I’m hesitant to start my rekkr sl playthrough with the blood colour patch in case it causes issues.

Blood color patches disable the "colored blood" setting for Cacodemons and Barons since Rekkr doesn't have these monsters. It's pure cosmetic, you can safely play without them.

[Pixel Fiend]

 

Crispy vs Woof

I would love it if Woof could be my default source port for everything but what it lacks most for me is brightmaps. Always noticeable. In Crispy you have lovely glowing switches, pickups and other things. Sweet effect like with the pulsating armor helmets. You just can't see that in Woof. If there's a chance you'll port such option in the future, I'm here to remind that it will the most perfect decision. 

Edited January 2, 2022 by game