Blurry texture issue

OpenGL OpenGL: Basic Coding
1

Hi !

I am currently using OpenGL in order to render pixel art texture in 3D (billboards). And I’m using :

    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
    glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
    glPixelStorei(GL_UNPACK_ALIGNMENT, 1);

The problem is that with my old laptop my rendering is fine all the texture (even the distant ones) are really sharp. But I bought a new laptop. With this new laptop when I run my code distant texture are blurry not sharp as they are when I use my old laptop.
It’s like if there is an AA enabled…

Thank you in advance for your help…

2

Well I do not know why but the windows text resize feature in which we can choose between 100% 125% etc will influence the rendering… Well do you know why this feature influence the OpenGL texture rendering ?

3

Regarding your first question:

It could be down to driver settings of your new vs. old laptop. I recommend checking the anisotrophic filter settings as well as the other texture filtering options in the driver.

From a code perspective, to make the textures look nicer, change the min/mag filters from GL_NEAREST to Gl_LINEAR at the very least. Alternatively, going a step further, you can use mipmapping, like so:

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST_MIPMAP_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glGenerateMipmap(GL_TEXTURE_2D);

Regarding your second question: I believe the MS Windows resize feature influences the glViewPort and thus changes the rendered result.

Hope this helps.

4

It’s more likely that Windows is lying about the size of the window.

5

I agree, thats what I meant, I just phrased it poorly.

6

Yes. This annoying thing is supposed to be a “value add” from having the entire screen run through the Windows DWM compositor before it’s displayed (except for the fullscreen flip special-case). Ooh, cool. So you can render at one res and then resize the whole thing on-the-fly to another res and make the screen blurry.

It’s dumb. Just set this to 100% and leave it. Then the pixels you render end up being pixels on your monitor’s framebuffer, without any value-add blurring from the compositor.

Also related to this blurring/effective res thing…

On some laptops (e.g. Optimus), you have to jack with the Intel GPU settings to get it to stop screwing around with your desktop res and scaling as well.

As mentioned, this isn’t going to mess with your OpenGL context state (e.g. glViewport / glScissor settings). As far as the window size, what usually happens with typical Win32 creation code is that the size/position of your window is clamped from what you request so that it fits on the desktop, which may result in the size you originally request being different from the size you end up getting. You need to handle that case, if you don’t preclude it with your window size/placement code.

Plus, if you’re rendering to an offscreen FBO and then blit to the window, you need to flow this to your offscreen FBO creation too. What can happen is you try to create both to be WIDTH1 x HEIGHT1 pixels, the window size gets clamped to WIDTH2 x HEIGHT2, and then your blits from MSAA offscreen FBO to window start failing because you’re trying to resize and downsample in the same blit. Unextended glBlitFramebuffer() won’t do that (you’ll get a GL_INVALID_OPERATION if you try). You’ll either need to use 2 blits, or use EXT_framebuffer_multisample_blit_scaled so you can do both operations in 1 blit, or better just make sure you create the offscreen FBO so that it’s the same size (in pixels) as the final, clamped window size.