BUG: toggling gl_no24bit at runtime has no effect, remains latched

[hemostx]

ezQuake version:
3.6 since 015d762 (found by bisecting from 3.6a0 merge => HEAD)

OS/device including version:
W10 20H2, happens on either my desktop/GTX1070 or laptop/intel hd 4000, so probably irrelevant.

Describe the bug
From the console, changing gl_no24bit and doing a vid_restart has no effect. The cvar remains at its original value, with the desired value latched and not switched to.

Changing it in the config file works, but you can't toggle it at runtime.

ezquake.exe -no24bit works.

Toggling at runtime works in older 3.* releases, likely up to at least 3.5a24 (the last 3.5 binary I had lying around).

To Reproduce
Steps to reproduce the behavior:

1. Make sure you have 24 bit textures in the qw filesystem and fire up ez 3.6, assuming the default gl_no24bit 0.
2. gl_no24bit 1
3. vid_restart
4. Enjoy 24 bit textures.
5. Check the cvar:

default 0
current 0
latched 1

Expected behavior
Same behavior as in older releases.

More details
Bisecting finds the guilty commit as 015d762

MINOR: Re-register fewer non-latch cvars on vid_restart

which essentially changes from

Cvar_SetCurrentGroup(CVAR_GROUP_TEXTURES);
...
Cvar_Register(&gl_no24bit);
...
// latch cvars
Cvar_Register(&gl_wicked_luma_level);

to

if (!host_initialized) {
    Cvar_SetCurrentGroup(CVAR_GROUP_TEXTURES);
    ...
    Cvar_Register(&gl_no24bit);
    ...
}
// latch cvars
	Cvar_Register(&gl_wicked_luma_level);

It would be tempting to pull registering that cvar_register out, however the issue appears to be the combination of this check with CVAR_LATCH_GFX.

When changed, CVARS with CVAR_LATCH_GFX show the helpful "xyz requires a vid_restart to take effect", which I suppose would be appropriate to add to several of the texture cvars in that group : gl_picmip, gl_miptexlevel, gl_external*, as those do indeed require a vid_restart to take effect, but the user has to figure that themselves.

So just for kicks, on HEAD, I disabled latching on gl_no24bit in r_textures_cvars.c:
cvar_t gl_no24bit = { "gl_no24bit", "0"/*, CVAR_LATCH_GFX*/ };
Toggling at runtime now doesn't say "requires a vid_restart", and switches as expected with a vid_restart.
I went further and added the property to gl_picmip:
cvar_t gl_picmip = { "gl_picmip", "0", CVAR_LATCH_GFX };
and after a rebuild, this now warns about "requires a vid_restart", and remains latched without applying the change.

Variables that would be affected by this:
gl_max_size, gl_scaleModelTextures, gl_scaleModelSimpleTextures, gl_mipmap_viewmodels, gl_scaleTurbTextures, gl_scaleskytextures, gl_miptexLevel, gl_no24bit, gl_picmip, gl_lerpimages, gl_externalTextures_world, gl_externalTextures_bmodels.

These are in fact latching and therefore should probably be flagged as such and pulled back out of that block. Now, doing that causes issues with QMB particles when toggling gl_no24bit (turning off = revert back to stock particles as expected, turning on = either missing/partial QMB effects, or a client crash when starting a QMB effect).

Note: special cases on gl_max_size and gl_miptexlevel which should be latching and need an OnChange to warn about allowed texture sizes etc.

[meag]

Hi hemo - appreciate you've mentioned other issues at the bottom here, commit only fixes the bug. Can you create REQ for the other cvars, and we'll look at splitting /vid_restart from /vid_reload, which would reload textures only and not just create new window/opengl-context etc?

[hemostx]

Here's the REQ. I'll try to get more intel on the QMB issues I stumbled upon for an other issue.