If it (or Documents/My Games/dhewm3/) can't be created, show a windows
MessageBox with an error message and exit.
Would've made #544 easier to figure out
At least VS2017 doesn't like the big string literal of
proggyvector_font_base85.h (its limit is 64KB, Error C1091), so go back to
using proggyvector_font.h (which contains an int32 array) for MSVC..
Keep the base85 version around for proper compilers, because (unlike
the non-base85 version of the font) it works on Big Endian machines.
It seems like VS2022, maybe even some point release of VS2019 removed this
limitation (our CI build succeeds), but I couldn't find any details about
that change.
Based on whether handleMouseGrab() in events.cpp sets
GRAB_ENABLETEXTINPUT or not.
Should prevent the issue that on macOS pressing a button for longer
while playing (as one does, e.g. to run forward) opens a popup menu
with alternative characters (like "è", "é", "ê", etc for "e")
fixes#632
The bug was most probably not caused by D3_SDL_X11 but by
GetDefaultDPI() returning -1.0 which GetDefaultScale() then divided by
96 and rounded to 0.0, which is not a good scaling factor.
I decided to kick the D3_SDL_X11 special case anyway.
also changed that logic a bit so FormatMessage() is only called when
actually used
and while at it, fixed the build with mingw-w64 on my system
(somehow an SDL header used strcmp() and that didn't work with
`#define strcmp idStr::Cmp` from Str.h)
When requesting < 1 MB, _alloca16() is used, otherwise Mem_Alloc16().
Furthermore you must pass a bool that will get true assigned if the
memory has been allocated on the stack, else false.
At the end of the function you must call Mem_FreeA( ptr, onStack )
(where onStack is the aforementioned bool), so Mem_Free16() can be
called if it was allocated on the heap.
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
- 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
assert( ret.width == glConfig.winWidth
&& ret.height == glConfig.winHeight );
in GLimp_GetCurState() triggered, because SDL_GetWindowSize(),
which was used to set glConfig.winWidth/Height in
GLimp_UpdateWindowSize(), returned different values than
SDL_GetWindowDisplayMode().
Now use SDL_GetWindowDisplayMode() in GLimp_UpdateWindowSize() so it's
at least consistent.
However it seems like SDL_GetWindowSize() returns the correct values
(IN THAT CASE), because with this change the mouse cursor doesn't work
that well (in the specific case described above).
In the end this is an SDL or Wayland bug or something, and I can only
recommend not using "real" fullscreen mode with Wayland, as it's fake
anyway (Wayland doesn't allow switching the display resolution, so
you get a magically scaled borderless fullscreen window at best)
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
Toggling with Alt-Enter relies on idRenderSystem::IsFullScreen() which
returns glConfig.isFullscreen
That can only work if GLimp_SetScreenParms() actually sets
glConfig.isFullscreen
Thanks j4reporting for reporting this! :)
"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)
- convert to/from ISO8859-1 (Doom3's "High ASCII" encoding)
- count Unicode codepoints in UTF-8 string
- cut UTF-8 string off after N codepoints
- use the conversion function to replace iconv in sys/events.cpp
In the main menu the ImGui/SDL/System cursor was only drawn when it was
over an ImGui window, so only the Doom3 cursor is shown when outside
of ImGui windows.
The only problem with this is that the Doom3 cursor is only shown in
the parst of the window actually covered by the main menu, not the black
bars that are drawn on the left/right for widescreen-resolutions when
scaling the menu to 4:3 is enabled (which it is by default).
So now the ImGui cursor is also drawn when the cursor is on those
black bars (if any).
Also tweaked the windowtitle background colors a bit.
* Binding menu makes sure that the AllBindingsMenu always gets focus
when opened
* Give binding-related popups slightly rounder edges
* Move Game Options tab behind Video and Audio Options
* Make warning overlays a bit less translucent
Pause the game (with g_stopTime) when the settings menu is opened
while ingame, unpause it when it's closed.
If the menu is open while ingame and an ImGui window has focus,
the mouse cursor is shown. If the player clicks outside an ImGui window,
it gets unfocused and the cursor is hidden and the player can look
around. Pressing F10 (or whatever key is bound to "dhewm3Settings")
will give focus back to an open ImGui window, pressing it again then
will close the settings window, pressing it once again afterwards will
open the settings window again.
handleMouseGrab() (in sys/events.cpp) now checks if sys_imgui thinks
that a cursor should be shown (via D3::ImGuiHooks::ShouldShowCursor())
and if so, shows it and ungrabs the mouse. This, together with
D3::ImGuiHooks::NewFrame() checking ShouldShowCursor() to (unset)
ImGuiConfigFlags_NoMouseCursorChange, should prevent flickering cursor
problems that sometimes occurred when ImGui's SDL2 backend and dhewm3
disagreed on whether the cursor should be visible.
Also fix MSVC build: For some reason Microsoft's sad excuse of a compiler
only sets __cplusplus to a value from this millenium if the
/Zc:__cplusplus compiler option is set, but that's only supported from
VS2017 15.7 on. The alternative is to use _MSVC_LANG, which always holds
the version that __cplusplus *should* have...
