QZDoom - ZDoom with True-Color (Version 1.3.0 released!)

[dpJudas]

The scaling code is currently running deep inside the GL part of the codebase (hence why you can't enable those scalers for the software mode). A pull request for this stuff should be sent to GZDoom.

[RaVeN-05]

So in software mode scalers not works for now?

Can you tell please about linear texture filtering? what the idea behind that how it works?

i found two references but looking into source code does not tell me anything.

xoffset -= FRACUNIT / 2;
int tx0 = (xoffset >> FRACBITS) % mip_width;
if (tx0 < 0)
tx0 += mip_width;
int tx1 = (tx0 + 1) % mip_width;
source = (BYTE*)(pixels + tx0 * mip_height);
source2 = (BYTE*)(pixels + tx1 * mip_height);
height = mip_height;
texturefracx = (xoffset >> (FRACBITS - 4)) & 15;

Code: Select all

			xoffset = MAX(MIN(xoffset - (FRACUNIT / 2), (mip_width << FRACBITS) - 1), 0);

			int tx0 = xoffset >> FRACBITS;
			int tx1 = MIN(tx0 + 1, mip_width - 1);
			dc_source = (BYTE*)(pixels + tx0 * mip_height);
			dc_source2 = (BYTE*)(pixels + tx1 * mip_height);
			dc_textureheight = mip_height;
			dc_texturefracx = (xoffset >> (FRACBITS - 4)) & 15; 

[Graf Zahl]

So in software mode scalers not works for now?

No. The only place where the scaler is called is in the code that generates OpenGL textures.

[ZZYZX]

Why exactly are scalers implemented as physically scaling and not shaders anyway? (unless they are actually shaders now and I'm living in 2010)
I mean this produces epic lag and memory consumption.

[RaVeN-05]

Hello Graf Zahl, can you please include my scaler in GZDoom?
I very like my work and want it to be used in engine.
The code is not so smart =( it need to be refactored, and i can't make it better sorry =( i am very unskilled at coding.

Maybe you can explain how that linear texture filtering works? because i looking into QZDoom source code and it very genious to me.

[dpJudas]

Can you tell please about linear texture filtering? what the idea behind that how it works?

It is just standard GL_LINEAR filtering like samplers do in OpenGL. It works by grabbing the four nearest pixels and then does a linear interpolation between them. Pseudo code:

Code: Select all

vec4 linearFilterRepeat(vec2 position, vec4 *texture, int texwidth, int texheight)
{
    position.xy -= 0.5;
    int tx0 = int(position.x) % texwidth; if (tx0 < 0) tx += texwidth;
    int ty0 = int(position.y) % texheight; if (ty0 < 0) ty += texheight;
    int tx1 = (tx0 + 1) % texwidth;
    int ty1 = (ty0 + 1) % texheight;
    vec4 p00 = texture[tx0 + ty0 * texwidth];
    vec4 p10 = texture[tx1 + ty0 * texwidth];
    vec4 p01 = texture[tx0 + ty1 * texwidth];
    vec4 p11 = texture[tx1 + ty1 * texwidth];
    float a = position.x - floor(position.x);
    float b = position.y - floor(position.y);
    float inv_a = 1 - a;
    float inv_b = 1 - b;
    return p00 * (a * b) + p10 * (inv_a * b) + p01 * (a * inv_b) + p11 * (inv_a * inv_b);
}

The code you pasted is the X direction of the above. It looks a little bit more complicated because it uses integer math for it with just 4 bits for a, b, inv_a and inv_b. This is to avoid overflowing when doing the linear interpolation in the drawer. Only the X direction is constant across a wall column, so that's why it precalculates that part of the equation.

[Graf Zahl]

Why exactly are scalers implemented as physically scaling and not shaders anyway? (unless they are actually shaders now and I'm living in 2010)
I mean this produces epic lag and memory consumption.

Because their processing cost is far too high to do it in real-time while rendering.
Imagine all that lag each frame...

[ZZYZX]

Cost of processing is per drawn pixel, if I remember correctly how GLSL works.
Now, a lot of applications have realtime HQnx to scale 320x200 to proper sizes every frame (most obvious example being dosbox) and it works okay.
And again, if I remember how GLSL works, it shouldn't matter performance-wise if something is applied to all textures in a frame or to a complete frame.

Was there any actual testing conducted to see if shaders would lag?
The lag in current scaler comes from the fact that it'd process all the stuff on CPU then have to upload it to the GPU. It won't do that if everything is done only on GPU.

In addition: I think some Doom ports are capable of HQnx rescaling in software. Not sure. They might do the static one too.

[Graf Zahl]

Nobody ever implemented a shader to do this. The algorithms aren't even tailored to run them on single pixels. The only good looking one is xBRZ anyway and its source is 50kb which is heavily optimized for upscaling images, not single pixels.

[RaVeN-05]

//i see there will be much easy to understand it, just mathematics, i still experience difficulties on what we should give to func as params and what it returns, probably it returns single pixel?
vec4 linearFilterRepeat(vec2 position, vec4 *texture, int texwidth, int texheight) // what is vec4? vec2? its struct with 4 or 2 int fields right? what position we will send? vec4 * texture is pointer to array of rgba ?
{
position.xy -= 0.5; // position.x-=0.5, and position.y-=0.5; overloaded
int tx0 = int(position.x) % texwidth; if (tx0 < 0) tx += texwidth;//tx means its tx0?
int ty0 = int(position.y) % texheight; if (ty0 < 0) ty += texheight;//same as above
int tx1 = (tx0 + 1) % texwidth;
int ty1 = (ty0 + 1) % texheight;
vec4 p00 = texture[tx0 + ty0 * texwidth];
vec4 p10 = texture[tx1 + ty0 * texwidth];
vec4 p01 = texture[tx0 + ty1 * texwidth];
vec4 p11 = texture[tx1 + ty1 * texwidth];
float a = position.x - floor(position.x);
float b = position.y - floor(position.y);
float inv_a = 1 - a;
float inv_b = 1 - b;
return p00 * (a * b) + p10 * (inv_a * b) + p01 * (a * inv_b) + p11 * (inv_a * inv_b);//overloads?
}

what about original size and resize ? opengl can do any resize, 2x, 3x, 1,92354x e.t.c

i mean algorithm must somehow to know the original pixels to not replace them with new recalculated pixel, avoid loss of data

[dpJudas]

Please see the OpenGL 4.5 specification, section 8.14.2 "Coordinate Wrapping and Texel Selection" on pages 245 to 248. That's a purely mathematical explanation of the function I wrote in my last reply.

It doesn't modify the source texture, it always works in 2x2 blocks (or 2x2x2 for a 3D texture), and texelGather is the GLSL function for fetching p00, p01, p10 and p11. In my pseudo function, vec4 is the equivalent of a RGBA vector of floats as seen by GLSL. The 'position' input is where in the texture it is sampling from. If you're looking for a more detailed explanation of how linear filtering on a GPU works, try google around. I'm sure there must be plenty of articles out there that explains it.

[RaVeN-05]

Wooh damn, i am sorry i am stupid, book is hard to understand. And English is not my native i am Ukrainian.

Thank for helping.
Sorry for wasting your time =(

[dpJudas]

Sorry if I sounded a bit grumpy. What I was trying to say is that there's probably a lot of articles out there that explain (bi)linear filtering with images and stuff. The wikipedia page for bilinear seems to have a pseudo example that's very close to what I wrote here.

[RaVeN-05]

Its all okay =). Sorry for offtopic i always wondering, how people can come to that "hi-tech" programming (lets say).
I am always learning C++, by book(two finished), by courses (three finished. But i still at same place. Ok i can code, i can read something not so hard (high skilled), but i am always impressed how other can do it. (Sorry for long msg, i think you know...)

ON TOPIC:
Does it hard to implement in software render (or in OpenGL , never seen before) a bicubic filtering? https://en.wikipedia.org/wiki/Bilinear_filtering
look at first picture on left side. And https://en.wikipedia.org/wiki/Bicubic_interpolation (its very beautiful), no rhombus (diamonds on pic). Very accurate)

Ok you right i found many articles by googling "bicubic zoom online" =0

I understand that it works like we get 4 nearest pixels and look how closer/farther they, by some formula we get percentage for each color (farther low percentage, closer high percentage) and do sum of all 4 of them(after % ), and fill new image and do not modify original. Just theory =) but on practice =(

A very big favor if somebody can write for me an app that have 4 pixels lets say red,white,cyan and black for example and function that accept image,size,new size. I even don't know how i will be glad and how i can say thank you, i don't even need to compile it, i need read and do all calculations by mind (i always understand everything that way)

[RaVeN-05]

Offtopic: don't forget my post above =)

Knowing in theory what bilinear filtering is, and what i done in sed2x and resed2x (my scaler app)
i can say in theory its possible to make sed2x work on any rezise values not only 2x.

What idea behind my app:
we have image RCBWA (i mean red dot, cyan dot, blue dot, White dot, Alpha)
RCA
BWW
RAC

size 2x

so we have

RaCaAa
aaaaaa
BaWaWa
aaaaaa
RaAaCa
aaaaaa

whare a-is alpha nevely added
now we fix alpha to make it more rounded. (hard to explain, look source)

main steps, cycle run on all nevely inserted alphas, and choose between 4 pixels on diagonals who of them is much closest to each other by color.

RaCaAa
a?aaaa
BaWaWa
aaaaaa
RaAaCa
aaaaaa

? = BC or RW
BC is (0,0,255)-(0,255,255)=mod(0,-255,0)=(0,255,0) get sum 0+255+0=255
RW is (255,0,0)-(255,255,255)=mod(0,-255,-255)=(0,255,255) get sum 0+255+255=510
Who is closest? 255 < 510 right 255 less than 510 so BC is closest colors to each other

? = average(BC)=(0,127,255) (B+C)/2

after we go trough all diagonals, we open second cycle that do the same with horizontal and vertical and choose closest colors and fill image.

Last step:
some pixels remains unused and they present in picture making it looks ugly
so open last cycle
where we go only on unused pixels (i mean near of them where is alpha)
if two pixels unused is close to each other do average to.

For now with theoretical knowleadge of bilinear its possible to do same as above but much faster and using any resize not only 2x

(like in GL_LINEAR) interpolation by selecting from 4 nearest pixels only two that close to each other.
and second cycle is ignore processed (used pixels) and interpolate only unused between each other, or even faster but uglier -> interpolate unused like regular GL_LINEAR, also we can even remove unused pixels, but it loss of data and it makes image very good looking but not completed and it noticefull.

For example very small pictures where we see face and each eye is cyan , surrounded by skin, after we magnify it, it remains like single pixel, so small eyes.