This is necessary to stop the sky in some rerelease maps, eg base1,
from spinning: these maps set a 'skyrotate' value, but explicitly
disable it with the new 'skyautorotate'.
Decouples texture coordinates from lightmap coordinates to allow for
higher resolution lightmaps, and also avoids lightmap misalignment when
shadows span surfaces with differing texture scale.
Use fullbright if not lights provided, same logic used by default
for gl renders and way to show something for ReRelease version
while real support is not implemented yet.
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.
the HunkAlloc size calculated in calTexinfoAndFacesSize() was too
small because that map has a *massive* water poly.
Unfortunately it's not feasible to calculate the correct size
(it depends on the size of the poly, for which I'd need the vertex
coordinates, but to get them I'd have to load them first, which requires
the allocation...), but allocating 5MB extra (instead of 1) made it work
