ZDoom

Wait, you're the OpenAL-Soft/libopenal1 maintainer? Awesome.

It's actually working fine for me in both X11 and Wayland native output windows, both running from the command line and invoking directly from the windowing environment. However, I am using dependencies repackaged from Ubuntu 24.04, since I actually keep all my build environments in containers.

I have regular old SDL2, as well. Same version as Chris, above. This machine is in as close to an "out-of-the-box" configuration as I can manage (most software is installed via Flatpak or other containment mechanisms, only a handful of programs are installed from the package repo), so it is ...

Yup, same behavior I'm getting. It'll respond to CTRL-C, but it never actually spawns the main window.

Just to see if it made any difference, I tried switching to an old X11 session. Didn't help.

My actual user session is running in Wayland. I'm just using GZDoom's CMake script with all of its default settings, so it's running that through X11 (XWayland) in KDE. If I roll back to commit 4a8421099, the one immediately before yours, re-run the build changing no settings whatsoever, and launch ...

In recent dev builds, I can start GZDoom and get the IWAD picker menu, but the actual startup process stalls after that. It never opens the main game window; it just sits there and does nothing. Building GZDoom on my own machine, I've narrowed it down to the following commit. The commit immediately ...

On the latest dev build (gzdoom-x64-g4.11pre-203-gc6978c23a as of this writing), there is a rendering glitch that shows up on E1M9 and E1M6 in Ultimate Doom when using the hardware renderer. It manifests as a "hole" in the floor and ceiling around a key card. This does not occur in the software ...

Platform: Windows 10, x64 Commit: 2be13e1b9f2735660fb147048f35d23628023214 ("- changed shader loader to load only one shader at a time") Compile environment: VS 2022, building x64 Bug: When the Vulkan renderer is selected, GZDoom crashes to desktop with a write AV to a null address, right after ...

Here's the last one I've got. It's a Core I7-1165G7, which is interesting because it has the latest generation of Intel's onboard graphics, using the "Xe" architecture. Vulkan appears to perform the best here, but is totally unusable because the floors and ceilings are just completely missing, as if ...

Here's a lower-end setup from a few years ago. Intel i7-8550u, onboard graphics, in a notebook. If I get the chance, I'll also try to run it on a little NUC I've got with an i7-1165g7. That one might be interesting because it should be representative of the current wave of onboard graphics in laptop ...

Modern desktop hardware, discrete GPU.

Amusing how slow the bridge in Frozen Time is compared to...everything.

Commit SHA: a8a5613675e1760e079acc6a3992c6e362601cdb

On launch, regardless of IWAD selection, I'm getting the following error on startup:

gzdoom.pk3:zscript/engine/base.zs, line 415: The function 'Screen.GetTextScreenSize' has not been exported from the executable

It seems to be a consequence of the font/palette changes that were recently introduced. Just to possibly save the devs a little time: This is the stack: > gzdoom.exe!V_ApplyLuminosityTranslation(int translation, unsigned char * pixel, int size) Line 680 C++ gzdoom.exe!FSpecialFont::LoadTranslations ...

Git commit hash: ff9a56dc0b3e3954c1b479c753cb35f26b73d9d0 (defect appears to have been introduced by e6c96bcb759b938ea3a5a92b2a9d03559cea97f7) Game(s): Probably all; confirmed that this at least repros with Hexen, Doom 2, and Doom. Happens with all renderers. Platform: Windows (x64), self-built, VS ...

Yup, just pulled and rebuilt again this afternoon and it looks like all of the really blatant texture sizing and incorrect texture stuff has been fixed by now.