Over the last years high dpi displays became increasingly popular. We
already implemented very basic high dpi support for Windows several
years ago by setting the "please don't scale us" option. Linux (and
all other unixoid platforms) hadn't a real understandig of high dpi
and everything involved until the advent of Wayland and finally the
*fractional-scale-v1* protocol last autumn.
Since then SDL (even bevore the protocol was finalized) and all three
common Wayland compositors (Gnome, KDE and wlroots) have grown support
for the protocol and are now high dpi aware. In a high dpi aware world
the choice is scale yourself or get scaled by the compositor. The later
option isn't so good for fast paced games like Quake II, it introduces
blur and slugishness. Therefore implement hig dpi awareness through SDL.
This isn't perfect right now:
* SDL is still getting high dpi awareness fixes with every release. High
dpi awareness in YQ2 is currently limited to at least SDL 2.26 and we
may rise the required version even more if necessary.
* There are stll bugs in the compositors. For example Gnome 44.1 has a
tedency to misscalculate the space occupied by the fullscreen window,
the game ends up wit a white bar on top. sway even misscalculates
some scaling factors: https://github.com/swaywm/sway/issues/7463
* SDL hasn't got a reliable way to get the real non scales desktop
resolution.
Because of this:
* High dpi awareness is currently restricted to Wayland. Let's get one
platform right before we implement it for everything else.
* It's hidden behind `vid_highdpiawareness` and disabled by default.
High dpi awareness is implemented by setting `SDL_WINDOW_ALLOW_HIGHDPI`
on the window. After the window and rendering context are created
`SDL_GL_GetDrawableSize()` or `SDL_GetRendererOutputSize()` are used
to query the actual drawable size and the internal representation is
overwritten with it.
This would scale the fullscreen window over the full screen, no matter
what resolution was selected. Some work arounds are implemented to
(mostly) keep the old behaviour were resoltions lower than the desktop
resolution weren't scaled. There is one inconsistency: While the non
high dpi aware soft renderer always scaled over the full screen, the
high dpi aware variant doesn't. This is a restriction by SDL Renderer.
Setting native fullscreen was broken before when running on high dpi
displays and it's not fixed. This is caused by SDL being unable to
determine the real resolution (or whatever the compositor thinks the
real resolution is). Depending on the compositor or if the client is
high dpi aware the correct resolution must be set by hand **or** auto
setting with `r_mode -2` must be used. Resolution detection was switched
to `SDL_GetCurrentDisplayMode()` because it's somewhat less problematic
than `SDL_GetCDesktopDisplayMode()`.
The renderer API was extended by one function pointer `*GetDrawableSize`
used to communicate the actual drawable size between renderer and
client. The API version was bumped to 6. I'll fix ref_vk before pushing
this change to master.
Haptic maximum effect distance value, By default this cvar is `100.0`.
Any positive value is valid. E.g. effect of shot near barrel to barrel
has 58 points.
Changed 6 cvars for stick layout to 1; includes menu option
Axial deadzone replaced with radial one, 6 cvars to 2
Expo different for each thumbstick (1 cvar to 2); sliders included
Expo applied to full joystick vector magnitude, instead of per axis
Deleted "joystick_up" ("updown" function) and its sensitivity
Cvar to choose between "yaw" (0) or "roll" (1) axis of the controller
to turn (change your yaw) in-game.
Cvars to change pitch and yaw gyro sensitivities.
Updated cvar documentation with new section "Game Controller".
r_lerp_list is to allow exceptions to r_2D_unfiltered (like for having
pixely UI in general, but filtered console background).
r_videos_unfiltered controls whether videos should be filtered or not
I also made r_nolerp_list CVAR_ARCHIVE, like users probably expect it.
There were complains that always generating footsteps is annoying,
because there will be footsteps while swimming or jumping. Refine
the cvar a little bit:
* `0`: No footsteps at all.
* `1`: Vanilla Quake II behavior.
* `2`: Always footsteps as long as the player has a ground entity.
* `3`: Always footsteps.
The changes the meaning of the values, `2` has become `3`.
Closes#738.
The commanders body entity is special, because it's spawned in god mode.
That's no problem in the baseq2 and addons campaigns. But it may break
some custom maps and prevents some hacks, one example is putting the
entity inside an killbox.
Submitted by Евгений T.
