Now also available in GL1. Includes a call to glClear at the beginning
of each frame, pointing to the same buffers that are discarded at the
end. When value is 1, operates over color, depth and stencil buffers.
When it's 2, only does depth and stencil, ignoring color. These
changes provide a performance improvement on mobile/embedded.
912b65ff74 changed mode `3` from random
playback to truly random playback, allowing the same track being played
several times in a row. Since some users might prefer the old behavior
move truly random playback to a new mode `4`. Add it to the menu and
finally document the `ogg_shuffle` cvar.
In addition to #1143
Since the SDL 1.2 day the SDL sound backend relied on the sound driver
supporting the requested audio format. That workes fine for drivers
support transparent conversions into formats supported by the hardware.
But it failes with drivers which are unable to do such conversions. As
long as we hardcoded the sound driver this wasn't a problem, because all
our chouces supported transparent conversions. When we removed the
hardcoded choices and started to rely on SDLs choices especially the
wsaapi driver - which is SDLs default choice under windows - failed.
wsaapi only guarantees support for AUDIO_F32LSB (other formats may be
supported, depending on the hardware), Quake II needs AUDIO_S16SYS or
AUDIO_U8.
Solve this by switching to transparent conversions through SDL. This way
Quake II can send whatever it wants to SDL and SDL will make sure that
it is in the right format before sending it to the driver.
This isn't necessary for SDL3, SDL3 doesn't support explicit formats and
always relies on transparent conversions.
Remove hardcoded wsaapi on Windows, it's no longer necessary.
Part of #1135.
Windows defaults to `wassapi`, which is a sensible choice. But WASAPI
only guarantees 32 bit float samples, anything else only works if the
driver or something supports it and YQ2 requires 16 bit samples. That
can be worked around by having SDL recode the audio, but I don't want
such a invasive change right before a release.
Another part of #1132.
Hardcoding default driver for some of the supported platform is a
remnant of SDL 1.2 and hasn't been necessary since SDL 2.0 a long
time ago. In fact it has a high properbility to break things, SDL
could easily end up with a non working driver.
When `s_sdldriver` is set to the newly introduced value `auto` the
driver is selected by SDL. In all other cases the string is the
driver name which SDL will be forced to.
This doesn't fix existing configs. Since the OpenAL sound backend has
been the default for nearly 15 years and we haven't received bug reports
for some other problem with the SDL sound backend in the past, I'm half
sure that there are next to users out there. These can reset the cvar
by hand if necessary.
Closes#1132.
Static arrays there have their dimensions swapped, they make more sense now.
Added important detail in gl1_lightmapcopies doc.
Also added doc for gl_polyblend, just because of its "popularity".
Available in both GL1 and GLES1. Keep multiple copies of "the same"
lightmap on video memory; they are actually different, because they're
used in different frames. This is a workaround for the usage of
glTexSubImage2D() for dynamic lighting, since modifying textures used
recently causes slowdown in embedded/mobile devices.
Controlled by gl1_lightmapcopies cvar; default in GL1 is `0`, while
in GLES1 is `1`.
Available only on GLES1, allows to use a "performance hint" to the
GPU to discard the contents of depth and stencil buffers after each
frame. Some hardware might want to reuse them, but Quake 2 doesn't
work that way.
Controlled by gl1_discardfb cvar, default `1`.
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.
