Video Display Problem

[ForbiddenEra]

When running vizdoom, whether from the example python scripts or running the executable directly from where it got put, the window immediately pops up in the x server and shows a single frame then goes white. When running directly (not in an example) it does accept input, I am able to start a new game..

When running the 'buffers' example, I get 5 windows, the 'initial' window which flashes a single frame as well as 4 others, screen buffer, depth buffer, labels buffer, map buffer, which all show up and render perfectly.

I've tried switching from software/hardware rendering on the x-server, disabling sound, trying different screen buffer formats..

While I have a somewhat unique environment, I'm not sure it should affect things. Other SDL2/GL/etc apps tested work fine. lzdoom seems to work, though it doesn't get into game, I can see the menu fine in xming, mobax actually just gives a white screen. Thinking some sort of hw accel/open gl is failing somewhere but not affecting everything?

Any ideas?

Edit: Setting the software canvas in lzdoom to sdl and restarting causes the same issue. I think it must be OpenGL issues; do the other buffers not use opengl to render in the buffers example?

Environment: Ubuntu 20.04 on WSL v2 with latest Windows Insider version, 460.20 GeForce drivers Vizdoom 1.18 Python 3.8.3 Xming / cygX / mobaX x servers on Win10 (same happens with all tested x-servers)

[Miffyli]

I tried to test this but unfortunately I have not setup any newer WSLs and could not setup things to run this. However running current pre-built binaries on Windows works as expected and same applies to Linux (KDE Neon). Given the previous quirks with WSL I would not be surprised that something like this happens :).

Edit: Setting the software canvas in lzdoom to sdl and restarting causes the same issue. I think it must be OpenGL issues; do the other buffers not use opengl to render in the buffers example?

The "buffer" windows are drawn with OpenCV2 utilities which (I believe) do not use OpenGL. Sounds like ZDoom is running correctly apart from not rendering images on screen correctly.

[ForbiddenEra]

glxgears works fine; so not sure if it's just opengl not being supported in any of the x-servers I was trying.

With software canvas set to opengl in lzdoom I get a crash when trying to start a level, but the menus appear to render fine:

fluidsynth: warning: SDL2 not initialized, SDL2 audio driver won't be usable

map01 - entryway

fluidsynth: warning: SDL2 not initialized, SDL2 audio driver won't be usable

(process:21678): GLib-GObject-WARNING **: 04:14:11.009: cannot register existing type 'IpatchSplitsType'

(process:21678): GLib-GObject-CRITICAL **: 04:14:11.009: g_param_spec_enum: assertion 'G_TYPE_IS_ENUM (enum_type)' failed

** (process:21678): CRITICAL **: 04:14:11.009: ipatch_type_install_property: assertion 'G_IS_PARAM_SPEC(prop_spec)' failed

(process:21678): GLib-GObject-CRITICAL **: 04:14:11.009: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed

(process:21678): GLib-GObject-WARNING **: 04:14:11.009: cannot register existing type 'IpatchSF2GenType'

(process:21678): GLib-GObject-WARNING **: 04:14:11.009: cannot retrieve class for invalid (unclassed) type '<invalid>'

** (process:21678): CRITICAL **: 04:14:11.009: file /build/libinstpatch-i701yY/libinstpatch-1.1.2/libinstpatch/IpatchSF2Gen.c: line 148 (_ipatch_sf2_gen_init): assertion `enum_class != NULL' failed.

(process:21678): GLib-GObject-WARNING **: 04:14:11.009: cannot register existing type 'IpatchSample'

(process:21678): GLib-GObject-WARNING **: 04:14:11.009: cannot register existing type 'IpatchItem'

(process:21678): GLib-GObject-CRITICAL **: 04:14:11.009: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed

(process:21678): GLib-GObject-WARNING **: 04:14:11.009: cannot register existing type 'IpatchSF2GenItem'

(process:21678): GLib-GObject-WARNING **: 04:14:11.009: cannot register existing type 'IpatchItem'

(process:21678): GLib-GObject-CRITICAL **: 04:14:11.009: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed

(process:21678): GLib-GObject-WARNING **: 04:14:11.009: cannot register existing type 'IpatchSF2ModItem'

(process:21678): GLib-GObject-WARNING **: 04:14:11.009: cannot register existing type 'IpatchItem'

(process:21678): GLib-GObject-CRITICAL **: 04:14:11.009: g_type_interface_add_prerequisite: assertion 'G_TYPE_IS_INTERFACE (interface_type)' failed

(process:21678): GLib-GObject-WARNING **: 04:14:11.010: cannot register existing type 'IpatchSF2VoiceCache'

(process:21678): GLib-GObject-WARNING **: 04:14:11.010: cannot retrieve class for invalid (unclassed) type '<invalid>'

(process:21678): GLib-GObject-WARNING **: 04:14:11.010: cannot register existing type 'IpatchItem'

(process:21678): GLib-GObject-CRITICAL **: 04:14:11.010: g_type_register_static: assertion 'parent_type > 0' failed

(process:21678): GLib-GObject-CRITICAL **: 04:14:11.010: g_type_register_static: assertion 'parent_type > 0' failed

(process:21678): GLib-CRITICAL **: 04:14:11.010: g_once_init_leave: assertion 'result != 0' failed

(process:21678): GLib-GObject-WARNING **: 04:14:11.010: cannot retrieve class for invalid (unclassed) type '<invalid>'

(process:21678): GLib-GObject-WARNING **: 04:14:11.010: cannot register existing type 'IpatchItem'

(process:21678): GLib-GObject-CRITICAL **: 04:14:11.010: g_type_register_static: assertion 'parent_type > 0' failed

(process:21678): GLib-GObject-WARNING **: 04:14:11.010: cannot retrieve class for invalid (unclassed) type '<invalid>'

(process:21678): GLib-GObject-WARNING **: 04:14:11.010: cannot register existing type 'IpatchConverter'

(process:21678): GLib-GObject-WARNING **: 04:14:11.010: cannot retrieve class for invalid (unclassed) type '<invalid>'

This requires a NOHUP to kill the process after.

gzdoom says 'Failed to load OpenGL functions' ..

Perhaps there's SOME opengl support but not enough? Is there any way to switch to just software rendering?

Or, as a semi-work around, can I just render the 'initial' buffer with OpenCV2? I suppose the window with the 'screen buffer' is essentially the same thing..? So if the example were working properly, the main window would be a copy of the screen buffer window?

I may just try running it on Windows as well, but I've also been playing with fastai which doesn't support Windows, I finally got that working beautifully with GPU support since the latest WI update came out yesterday.

...this is turning into a big hassle for someone wanting to avoid the hassle of partitioning something for Linux and dual-booting (I have many Linux boxes, but not either of my RTX systems)...

[Miffyli]

I dare not say anything regarding the OpenGL/Drawing stuff because it is completely out of my league, but I will give this advice: I strongly suggest to create the dual-boot to Linux and work there, as there might appear other libraries that do not play nice with WSL. I too once tried to get things working on Windows but eventually gave up as it became too much of a hassle.

Pre-compiled Windows binaries work fine and dandy but you have to have a very specific version of the Python installed (minor version much match, which is 3.7.4 for Python37, for example).

Or, as a semi-work around, can I just render the 'initial' buffer with OpenCV2? I suppose the window with the 'screen buffer' is essentially the same thing..? So if the example were working properly, the main window would be a copy of the screen buffer window?

Yup sounds like this could work. Of course you won't have control over the game, but if it is only the RGB image you want to see then this should work fine.

[ForbiddenEra]

Got it!

So, somewhere for using WSL it mentioned to do:

export LIBGL_ALWAYS_INDIRECT=1

Well, setting it back to 0 seems to have solved the problem..?

lzdoom still crashes. gzdoom still won't run.. vizdoom however, now works as expected..!

I suppose this issue can be closed; thanks for taking the time to respond anyway (considering my 'odd' environment and likelihood of it being an issue with that)

Anyone else trying this environment, that's the solution. :)

[ForbiddenEra]

I dare not say anything regarding the OpenGL/Drawing stuff because it is completely out of my league, but I will give this advice: I strongly suggest to create the dual-boot to Linux and work there, as there might appear other libraries that do not play nice with WSL.

Right? I'll get to it eventually. I even have Linux boxes with GPUs, just only AMD ones. I just need to get off my butt and buy a spare SSD for it.

Yup sounds like this could work. Of course you won't have control over the game, but if it is only the RGB image you want to see then this should work fine.

I could still control with the 'white' window, may have been awkward to have input going to a different window than the output, but that idea could've worked failing the rest.

I do have to say, as someone who's used Windows since 2.0 and Linux since 1.0, it's finally nice to see them trying to play nice together. I guess WSL2 is more just a VM now anyway but for certain tasks it's neat.

Thanks for the quick response anyway, this issue can obviously be closed.

Edit: side note - mouse input is not happy in this setup right now, haha.. moving it about 2px worth caused doomguy to spin about 1800000 degrees.

[mwydmuch]

Hi @ForbiddenEra, I'm happy that you found a solution for your problem and posted about it and thank you for trying running ViZDoom on WSL. As a Unix-only guy, this possibility never even crossed my mind. Good to know that it is may actually work!