Variant of GL1, meant for embedded/mobile devices only.
Build it with "make with_gles1".
For Windows, you'll need MSYS2 and a decent ANGLE implementation
(probably not worth the trouble).
Building with CMake only works in Linux, so it has been commented out.
glTexSubImage2D() calls are very slow, and are even slower when
the texture is big. Dynamic lighting changes are small compared
to the huge 512x512 size of the lightmap this option provided,
so it was detrimental to performance.
Original logic remains underneath if there's a need of a comeback.
The first try didn't take into account that an evil server could
override the filter list by sending a stuff command. Fix this by
hardcoding the filters for .dll, .dylib and .so. Make sure that the
filters are always applied, either when the download is requested
through the `download` command or because game data is missing.
This is just a poor mans fix, trying to rule out an obvious way to
inject code into the client.
`cl_nodownload_list` is a whitespace seperated list of strings, files
containing one of these strings in their name are never downloaded. Set
to `.dll .dylib .so` by default to prevent downloading libraries which
can be injected into client.
Closes#1114.
Controlled by gl1_biglightmaps cvar, works like new lightmaps.
Max size is 384x384; a bigger size is not justified.
Added a transparent border so colors from one picture don't bleed
into the next.
Controlled by new cvar, gl1_biglightmaps.
Size is now up to 512x512, for a max quantity of 8 lightmaps.
Should reduce rebinding of them, and reduce the number of calls
to glTexSubImage2D(), although it may increase data transfer on
each call.
Unlike the old, buggy one, this implementation follows the
texture chain, just like the standard execution path. It also
avoids doing the lightmap chains, since it has already done it
in the second TMU; there's no duplicated work for lightmaps.
No errors appear in the lava on the "boss1" map either.
It's still slow when having an overdraw of dynamic lights.
Further work is needed.
...and alter the render finding and fallback sequences to include GLES3
as the first fallback. This should have been done years ago, when GL3
became the clear better option above GL1.
With SDL3 the high dpi support is in much better shape than with SDL2.
And for Wayland the experience on high dpi displays is generally better
when the application is high dpi aware.
These commands can now "count" how many times they have been called,
similar to how "cycleweap" operates after #865.
This allows for changing to different weapons, instead of just going
"one down" or "one up".
New cvar "g_quick_swap" allows to enable/disable this behavior.
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.
