mirror of
https://github.com/dhewm/dhewm3.git
synced 2024-11-23 04:51:56 +00:00
699779e9ca
For some reason Wayland thought it would be clever to be the only windowing system that (non-optionally) uses the alpha chan of the window's default OpenGL framebuffer for window transparency. This always caused glitches with dhewm3, as Doom3 uses that alpha-chan for blending tricks (with GL_DST_ALPHA) - especially visible in the main menu or when the flashlight is on. So far the workaround has been r_waylandcompat which requests an OpenGL context/visual without alpha chan (0 alpha bits), but that also causes glitches. There's an EGL extension that's supposed to fix this issue (EGL_EXT_present_opaque), and newer SDL2 versions use it (when using the wayland backend) - but unfortunately the Mesa implementation is broken (seems to provide a visual without alpha channel even if one was requested), see https://gitlab.freedesktop.org/mesa/mesa/-/issues/5886 and https://github.com/libsdl-org/SDL/pull/4306#issuecomment-1014770600 for the corresponding SDL2 discussion To work around this issue, dhewm3 now disables the use of that EGL extension and (optionally) makes sure the alpha channel is opaque at the end of the frame. This behavior is controlled with the r_fillWindowAlphaChan CVar: If it's 1, this always is done (regardless if wayland is used or not), if it's 0 it's not done (even on wayland), if it's -1 (the default) it's only done if the SDL "video driver" is wayland (this could be easily enhanced later in case other windowing systems have the same issue) r_waylandcompat has been removed (it never worked properly anyway), so now the window always has an alpha chan |
||
|---|---|---|
| .. | ||
| aros | ||
| cmake | ||
| linux | ||
| osx | ||
| posix | ||
| stub | ||
| win32 | ||
| cpu.cpp | ||
| doom_icon.h | ||
| events.cpp | ||
| glimp.cpp | ||
| platform.h | ||
| sys_local.cpp | ||
| sys_local.h | ||
| sys_public.h | ||
| threads.cpp | ||