- 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...
turns out that __builtin_alloca_with_align() might releases the
allocated memory at the end of the block it was allocated in, instead
of the end of the function (which is the behavior of regular alloca()
and __builtin_alloca()): "The lifetime of the allocated object ends at
the end of the block in which the function was called. The allocated
storage is released no later than just before the calling function
returns to its caller, but may be released at the end of the block in
which the function was called."
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005falloca_005fwith_005falign
Clang also supports __builtin_alloca_with_align(), but always releases
the memory at the end of the function.
And it seems that newer GCC versions also tend to release it at the
end of the function, but GCC 4.7.2 (that I use for the official Linux
release binaries) didn't, and that caused weird graphical glitches.
But as I don't want to rely on newer GCC versions behaving like this
(and the documentation explicitly says that it *may* be released at
the end of the block, but will definitely be released at the end of
the function), I removed all usage of __builtin_alloca_with_align().
(Side-Note: GCC only started documenting the behavior of
__builtin_alloca and __builtin_alloca_with_align at all with GCC 6.1.0)
it could happen that UIs are added to the internal list twice,
and also that the last UI wasn't removed from the list when a new one
was focused fast enough.
That should work better now, I hope I didn't break anything..
- the gamepad button (or trigger) bound to attack (fire) now always
acts like the left mouse button in menus
- Display correct button name for "Back" button on Playstation-like
gamepads, even depending on whether it's PS3-like ("Select") or
PS4/5-like ("Share")
- Log some more information about detected gamepads
turns out SDL 2.0.12 added SDL_GameControllerGetType() which tells you
what kind of controller it is (xbox, playstation, nintendo, ..).
Using this to implement an auto-mode for joy_gamepadLayout, when it's
set to -1 (the new default).
This should still build with older versions of SDL2 (but won't have
that autodetection then).
The button names shown in the controls menu now depend on this CVar.
So if you set it to 1 (Nintendo), the "A" button (which, based on its
position, would be "B" on XBox/XInput gamepads) is actually shown as
"Pad A", and if it's set to 2 (Playstation), it's shown as "Pad Cross".
The "real" names, used in the config, remain the same and are based on
position: JOY_BTN_SOUTH, JOY_BTN_EAST, JOY_BTN_WEST, JOY_BTN_NORTH
- treat DPad as 4 regular buttons (was already the case mostly, but now
the code is simpler)
- rename in_invertLook to joy_invertLook and in_useJoystick to
in_useGamepad and remove unused CVars
- make controller Start button generate K_ESCAPE events, so it can
always be used to open/close the menu (similar to D3BFG)
- move mousecursor with sticks, A button (south) for left-click,
B button (east) for right-click (doesn't work in PDA yet)
- removed special handling of K_JOY_BTN_* in idWindow::HandleEvent()
by generating fake mouse button events for gamepad A/B
in idUserInterfaceLocal::HandleEvent()
- renamed gamepad/joystick actions and keys to have some meaning
for buttons (instead of just JOY1, JOY2 etc)
- compiles with SDL1.2 again (there gamepads aren't supported though)
- shorter names for gamepad keys/axis in the key bindings menu
