ZDoom

[quote="dpJudas"]Not bad phantombeta. My ideas for a shader version involved doing the linear filtering manually using texel fetches, but your version is better as it should work with anisotropic filtering I think.[/quote]
I believe I tried to do that at first too, but it just didn't work well.

[quote]I do wonder if the pow() could be replaced with something cheaper.[/quote]
Maybe, but I wouldn't know how to do so. That said, if you only make it possible to choose hardcoded values like with the "real" NormalNx, you could hardcode it as multiplications. That should be cheaper than a generalized exponentiation algorithm.

[quote]Supporting it for GZDoom is possible. It requires renaming the fragment input for the texcoord and putting a global variable with the old name in its place. At the start of the main() function (in main.fp) it could then apply the texcoord adjustment and store the result in the global variable.[/quote]
Huh, that's nice to know. Didn't know you can have globals in GLSL like that.

Not bad phantombeta. My ideas for a shader version involved doing the linear filtering manually using texel fetches, but your version is better as it should work with anisotropic filtering I think. I do wonder if the pow() could be replaced with something cheaper.

Supporting it for GZDoom is possible. It requires renaming the fragment input for the texcoord and putting a global variable with the old name in its place. At the start of the main() function (in main.fp) it could then apply the texcoord adjustment and store the result in the global variable.

Coincidently, Rachael was talking about making GZDoom's NormalNx into a shader too. Sounds like a great idea. :)

Essentially, this is a fragment shader-based emulation of the NormalNx texture upscaling mode that I came up with. It requires no extra VRAM, and only uses ALU operations. [url=https://gist.github.com/Doom2fan/7925b6149ded65ce6c9c319d2dc0cc8f]Here's the GLSL code for it.[/url]
Why am I suggesting it for Raze specifically? Because GZDoom has user shaders, and they get the texture UVs by accessing the vertex outputs directly, so this wouldn't work there*.

* (It'd need a preprocessing pass to replace any usage of the vertex output UVs with these modified UVs for it to work)