r_fillWindowAlphaChan is a hack to work around an older issue with
Wayland/Mesa, which has been fixed in Mesa 24.1 (and also seems to work
with current NVIDIA drivers). Additionally, in SDL3 the EGL-specific
(and thus mostly only affecting Wayland)
SDL_HINT_VIDEO_EGL_ALLOW_TRANSPARENCY has been replaced with the generic
SDL_PROP_WINDOW_CREATE_TRANSPARENT_BOOLEAN (that could also affect
other platforms), so it's harder to enable this only for Wayland.
I think most people using SDL3 will use a recent Mesa/driver versions,
so I don't enable it by default for SDL3 (SDL2 behaves like before).
However, with `r_fillWindowAlphaChan 1` the hack can be enabled anyway
(r_fillWindowAlphaChan defaults to "-1" which means "let dhewm3 decide
whether to enable this")
.. mostly by not making it use SDL_main.h, because it implements its
own SDL main functionality anyway.
However, I have no way to test this code and as long as SDL3 is not in
homebrew testing it in the CI build isn't easy either.
Refactored the pseudo-custom SDL_main code a bit: SDL_win32_main.c
is now only used for SDL1.2, SDL2 and SDL3 have a WinMain() function
in win_main.cpp that works pretty much like the SDL2 SDL_main or SDL3
SDL_RunApp() code - except that the argv[] strings passed to the Doom3
main() function (now renamed to SDL_main()) are encoded in ANSI instead
of UTF-8, so paths passed as commandline arguments, like
dhewm3 +set fs_basepath C:\SüperGämes\Doom3
work with the Win32 ANSI function used by Doom3 to handle paths and files.
For this I also moved the stdout/stderr redirection code from
SDL_win32_main.c to win_main.cpp and cleaned it up a bit
- use SDL_SetHint() to set the video driver to "dummy" for the
dedicated server
- adjustments for some more functions that now return bool instead
of int. I hope I found all cases of that now, at least in the generic
and Linux code, may have to take a closer look at Windows- and Mac-
specific code
.. except where SDL_Swap* is actually used (idlib/Lib.cpp).
Otherwise #if D3_IS_BIG_ENDIAN suffices, (NOT #ifdef, it's always set,
but to either 0 or 1!)
When applying the currently configured graphics quality preset
(it's set in the `com_machineSpec` CVar and applied with the
`execMachineSpec` command, or by using the menu), now soft particles
are disabled for all quality presets except for ultra, because this
feature has a noticeable impact on performance with some (slower) GPUs.
The previous commit didn't fix the issue for the pistol and only was a
workaround anyway. So I reverted that and fixed the issue properly.
The underlying issue is that the particle's material sets the
texture matrix (with "translate" or "scale" or whatever), and the soft
particle rendering code (and shader) didn't take the texture matrix
into account.
Now it does, in a similar way as the interaction shader code.
Fixes https://github.com/dhewm/dhewm3-sdk/issues/36
the base game entry is now called "Doom 3 (base game)" instead of
"dhewm3", which should be more obvious, and the d3xp entry now reads
"Resurrection Of Evil (d3xp)" instead of just "d3xp", which certainly
is clearer. d3xp now is also always second in the list (if installed)
Added the freshly supported perfected_roe and sikkmodd3xp mods to the
list of mods that need fs_game_base d3xp set, so they can be started
from the menu.
also added an entry for r_gammaInShader to Configuration.md
this avoid breaking the game DLL ABI (framework/DeclParticle.h is part
of the SDK), and for now doesn't make a difference, because that keyword
was introduced by TDM and thus is only used in their particle defs.
When we break the game ABI/API anyway (probably for high FPS support),
this commit can just be reverted
if this is not set, using fminf() actually calls that libm function,
if it is set, a CPU instruction that calculates the minimum is generated
instead. likely similar for other functions.
not sure if this causes trouble anywhere, but I don't think we rely
on NaN or INF?
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`
