separate out nearest filtering for UI, default it on

[Paril]

Split pt_nearest into two variables (the second one is named pt_nearest_2d), and default it to on, to match other Q2 engines/not cause blurry low quality UI textures.

Also fixes blurry non-standard fonts, since it was hardcoded to blur only the main font.

[res2k]

FWIW, the GL renderer seems to have two different cvars for this (gl_bilerp_chars, gl_bilerp_pics), maybe worthwhile to copy that approach? (The two vars also have different defaults - ..._chars defaults to off, ..._pics defaults to on.)

And/or, since the setting mostly concerns the UI, why not put "UI" somewhere in the cvar name, e.g. pt_nearest_ui or ui_nearest?

[Paril]

Not a bad idea. We could just copy the GL ones entirely, then it'd be closer parity.

"UI" is a weird term for Q2 because historically UI only refers to the menu & console, whereas the HUD refers to the HUD... several cvars make this distinction in other engines. It's annoying.

Is "bilerp" proper for the filtering used for them, though? I think it's only linear, not bilinear, with the current Vulkan pipeline.. not certain about that (edit: I think I'm just dumb, bilinear might be correct since there's two axis... I'm thinking of bicubic)

[Paril]

Changes done, now it's mostly parity with the GL system apart from the interpretation of the 1 value for pt_bilinear_pics.

[apanteleev]

Why not just reuse the same gl_bilerp... vars?

[Paril]

I guess you could - it's usually standard in engines with different renderers to use different cvars, since the gl ones don't make sense for a non-GL renderer. There's also the issue of 1 being semantically different in GL, since the VK renderer doesn't have the "scratch" system, so we'd have to make 1 effectively the same as 0 which might be a bit confusing (2 would be "enabled" for VK).

Same question could have been asked for why pt_nearest was made a new cvar instead of just overloading gl_texturemode. I just followed that path.

EDIT: it might be worth asking if we should instead have "renderer-independent" cvars... ie, ref_texturemode, ref_bilerp_chars, etc which would just be used by the different renderers appropriately, instead of needing separate ones or having "gl" ones basically a standin for "ref" (we could also add internal cvar aliases for vk/pt/gl_xxx -> ref_xxx, so that people used to the GL versions would still work). This does mean you'd lose the ability to have separate configs for GL and RTX mode though...