Fixes a bug where duplicate keyboard entries would occur in menu fields when using the keypad keys with num-lock on.
Adds `IN_NumpadIsOn` function returning the state of the numpad key.
Fixes a bug where duplicate keyboard entries would occur in menu fields when using the keypad keys with num-lock on.
Menu fields now mirror behaviour of the console field.
Removed keypad left arrow case from console key ignore list.
While trying to compile the yquake2 rebased heretic2 source from 0lvin, a name conflict with min\max of different parameter counts included by a std::cpp library occurred.
CL_RemoveFromQueue(qdlqueue_t *entry) free()s that entry, so the loops
that call q->next after CL_RemoveFromQueue(q) are accessing free'd
memory. Fix that by getting a pointer to the next entry before calling
CL_RemoveFromQueue().
Also did a tiny non-functional change to CL_RemoveFromQueue() to
make it easier to understand.
Fixed pause/un-pause on window focus gained or lost in pull request #1017.
Fixed ogg playback when switching video options, missed in #1004.
Fixed ogg playback when the last menu closed, misplaced in #1004.
Normal warping surfaces (SURF_DRAWTURB) with water etc should use
brightness 0.5*intensity (like they did before), but those with lava
should be brighter, so use 1.0*intensity in the shader.
The reason that intensity needs to be scaled down is that these surfaces
have no lightmaps, so they'd be rendered fullbright otherwise.
I'm using the simple heuristic of texturename contains "lava" to
detect lava textures.
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.
