After testing Doom CE (https://www.moddb.com/mods/doom-ce) I couldn't be more but excited to see this texture rendering style implemented in GZDoom. After a while my excitement became a slight dissapointment, particularly as I took a dive into the implementation found in the 3pointfiltering.pk3 file as it seemingly hacks in a shader filter in the rendering pipeline at the cost of breaking texture upscaling, filtering and automap rendering.
I have been wondering if this type of texture filtering could be natively added to GZDoom and so I did a quick research. This blog post (http://filthypants.blogspot.com/2014/12 ... n.html?m=1) talks about the feasibility of emulating this N64 hardware feature in software and provides HLSL and GLSL example implementations. Furthermore, there are some shadertoys which take a texture and spit out a pre-filtered texture (https://www.shadertoy.com/view/3lBXWc) (https://www.shadertoy.com/view/wdy3RW) (https://www.shadertoy.com/view/Ws2fWV)
I identify 3 insertion points: API call, hires texture cache and shader pipeline. AFAIK GZDoom calls in bilinear/trilinear filtering from the API and builds upscaled precached hires textures via dll libraries, correct? This later option would be less desirable since it would call for more memory usage and not bring the sharpest results. About the second one, I'm not savvy enough on OpenGL/Vulkan to talk meaningfully about it. Nonetheless, I think it would be a legitimately good feature, specially for N64 styled graphics as it would give them the intended look.
(Also, yeah, before some people shoot me off, I normally use no texture filtering, maybe resizing, and yes I also think bilinear/trillinear looks too smudged and ugly with Doom's low res original assets, but for Doom 64 the fuzziness just looks OH SO RIGHT
)
