turned out the whole problem with soft particles what that the vertex
shader used vertex.attrib[8] instead of vertex.texcoord (and with
nvidia drivers those are equivalent)
I integrated the shader source into the c++ code so I don't have to
ship glprogs/soft_particles.vfp
before it displayed the float values from the depth buffers as
byte-wise RGBA values, which looked weird and wasn't super helpful..
now it's displayed as luminance float (i.e. one float representing
greyscale), and transformed in the same way the TDM particle shader
transforms the depth values to doom units (and then scaled back to
0..1, with 1 representing 3000 units)
thanks to
https://community.khronos.org/t/cannot-read-from-depth-buffer-in-fs/76169/8
apparently the default doom3 texture filter was something using mipmaps,
which doesn't work so well for textures without mipmaps..
no idea why those two lines in idImage::CopyDepthbuffer() were commented
out, but they're needed (and also un-commented in TDM, I just missed
that when merging -_-)
disables partial vid_restarts, hopefully works around issues like
https://github.com/dhewm/dhewm3/issues/587#issuecomment-2206937752
Note that resizing the window by dragging it does *not* call vid_restart
at all, so if you're having issues that are fixed by a full vid_restart
you should also set `r_windowResizable 0`
- screenshots on native wayland (SDL_VIDEODRIVER=wayland) were black,
at least on Gnome
=> fixed(?) by reading from the default (back) buffer instead of
the front buffer
- after taking a screenshot, resizing the window (or switching to
fullscreen) was broken (window remained black or became invisible
or partly contained garbage), both with native wayland and xwayland
=> fixed by restoring the glReadBuffer state after reading the pixels
it's queried from SDL so it should be up-to-date.
Using it in GLimp_SetScreenParms(), as it mostly did the same SDL calls
to get the current state for the partial vid_restart
"vid_restart partial" only changes the window size or its fullscreen
(or windowed) state, without recreating everything.
If that fails (or antialiasing settings have changed), it will fall back
to a full vid_restart (this behavior is different than original
"vid_restart partial" that probably was implemented in Vanilla Doom3
but not dhewm3)
This is used for Alt-Enter (which toggles between fullscreen and
windowed state) and when pressing the Apply button in the new Video Menu
incl. setting in SettingsMenu
With SDL 2.0.5 and newer this change is applied immediately,
2.0.0 to 2.0.4 need a vid_restart
(with SDL1.2 we don't support it at all)
the stb libs, miniz and minizip are now always optimized to speed up
performance, esp. level loading times, in debug builds.
So far the stb libs implementation were dragged into the source file
that uses them, now I created additional source files just for them so
those can be optimized while the engine source files using those libs
can remain unoptimized in debug builds.
apparently this happens sometimes, but not often enough to reproduce
properly?
also some small changes (mostly formatting) to Configuration.md
refs #540
Added the ability to change the screenshot format with a new CVar:
r_screenshotFormat. This has four options: 0 (TGA), 1 (BMP), 2 (PNG),
and 3 (JPG). JPG quality can be selected with a new CVar:
r_screenshotJpgQuality. TGA is the default to preserve original behavior
from DOOM 3.
A new dependency on stb_image_write has been added. It has been
included. No additional configuration with CMake is required.
in the "Work around false positive GCC -W(maybe-)uninitialized warnings"
commit I changed that code.. but my change made it nonsensical,
of course we must get oldBounds before calling the callback which
changes the bounds, otherwise comparing the "oldbounds" with the
current bounds just compares them with themselves..
The assertion that triggered was "assert(iconvDesc == (SDL_iconv_t)-1);"
in Sys_InitInput() - because when loading a mod the window is recreated,
calling Com_ReloadEngine_f() -> idCommonLocal::InitGame()
-> idCommonLocal::InitRenderSystem() -> idCommonLocal::InitOpenGL()
-> R_InitOpenGL() -> Sys_InitInput()
Before that Com_ReloadEngine_f() calls commonLocal.ShutdownGame( true );
which calls the equivalent Shutdown() functions - except so far no one
called Sys_ShutdownInput() (which closes iconvDesc and resets it to -1).
Fixed that by making idRenderSystemLocal::ShutdownOpenGL() call it.
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
There were lots of places in the code that called Sys_GrabInput(),
some of them each frame.
Most of this is unified in events.cpp now, in handleMouseGrab() which
is called once per frame by Sys_GenerateEvents() - this makes reasoning
about when the mouse is grabbed and when not a lot easier.
Sys_GrabInput(false) still is called in a few places, before operations
that tend to take long (like loading a map or vid_restart), but
(hopefully) not regularly anymore.
The other big change is that the game now uses SDLs absolute mouse mode
for fullscreen menus (except the PDA which is an ugly hack), so the
ingame cursor is at the same position as the system cursor, which
especially helps when debugging with `in_nograb 1` and should also help
if someone wants to integrate an additional GUI toolkit like Dear ImGui.
